AzureAdministratorへの道の投稿 - Crieit

Azure Administratorへの道（6回：AzureAD周辺）

2020-12-26T13:03:48+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

知識が薄ぼんやりとしているAzureADのおさらい。

0. スキルの評価対応

アイデンティティの管理
　＞　Azure Active Directory (AD) を管理する
　＞　Azure AD オブジェクト (ユーザー、グループ、およびデバイス) の管理
　＞　ハイブリッドアイデンティティの実装と管理

1. AzureAD

・Office365やAzureの管理に利用する。
・カスタムドメインの登録が可能。
・AzureにはAADのユーザに対してRBACで権限を割り振る。
・ユーザの種類
　＞AADで作成したユーザ OR ドメコンから連携されたユーザ
　＞メンバー OR ゲスト
・ユーザの属性
　通常のドメコンと違うような属性は次の２つ。
　①利用場所
　　国を指定。これを指定しないとライセンス(Premiumライセンスなど)が割り振れない。
　②ユーザープリンシパルネーム
　　ユーザーのインターネット形式のログイン名
　　[email protected]みたいな形式
　　AzureやOffice365へログインする際のユーザ名の名前
・グループ
　動的にグループ割り当てができる
　→開発部所属のメンバーは開発部グループに自動所属のような感じか
　グループに有効期限を設け、破棄したりもできる
　グループの所有権があるユーザは、グループにユーザを追加できる。
・セルフパスワードリセット
　SMS、メール、秘密の質問、いずれかで変更。
・外部アクセス
　外部のメールアカウントを登録することで外部アクセスさせることが可能
・デバイス管理
　デバイスもAADに参加させ管理できる。
・アプリケーション
　3rd Partyのアプリとも統合できるケースがある。
　→Boxとか。
・条件付アクセス
　条件付アクセスポリシーにより設定。
　条件：ユーザ、グループ、デバイス、場所、などなど。
　制御：MFA、準拠デバイス指定、アプリ利用、利用規約を読ませる、などなど。
・アクセスレビュー
　現在のアクセス状況をレビュアが参照し、アクセス権を引き続き付与するか、
　破棄するか、などの判断・処理を実施できる。
・アイデンティティ保護（identiry Protection）
　脆弱性、リスクイベント、リスクを出しているユーザ、などが分かる。
　→Torブラウザで接近しているユーザは誰、MFAの設定をしない人がいる、とかが分かる。
　リスクイベントのレベルはポリシー（ユーザリスクポリシー、サインインリスクポリシー）で設定できる。
　→ポリシーに準拠しない場合はアクセスブロック、もできる。

2.ハイブリッドアイデンティティ

・オンプレミスドメコンとの同期。
・セットアップの流れ
★前提
　AzureAD：plazazurecontoso.onmicrosoft.com
　ドメコン：consoto.local
　→これをplazcontoso.comとして統一連携する。

　①AzureADの作成
　②AADでカスタムドメインの設定（plazcontoso.com）
　③ドメコンにUPN Suffix追加（plazcontoso.com）
　④同期対象ユーザのUPNを[user]@plazcontoso.comに変更
　　→powershellで一括変更
　⑤AzureADコネクトのデプロイ
　　→オンプレミス側にAADコネクト専用のドメコンを用意し、そこにデプロイする
　　　インターネットへ接続できる環境に存在する必要がある。
　⑥連携対象を指定（ドメインやOUなどで指定）
　⑦AzureADのごみ箱を有効にする

・ドメインフォレスト、AADコネクト、AzureAD
　①ドメインフォレスト：AADコネクト = N:1
　　複数フォレストの情報を１つのAADコネクトに集約はできる
　②AADコネクト：AzureAD = 1:1
　　AzureADとAADコネクトは1つに対して1つ
　　なので、もしAフォレストはAzureAD1、BフォレストはAzueAD2に連携、
　　という場合はAADコネクトは2台必要。
・AADコネクトの３つのSSO（シングルサインオン）認証
　①パスワードハッシュ同期
　　ドメコン→AADコネクト→AzureADの流れでハッシュ化したパスワードを連携し、
　　その内容を元にAzureADは認証を行う方式。
　　AzureADアカウントの有効期限は「無期限」になる。
　②パススルー認証
　　（流れ）
　　AzureADの認証情報をAADコネクトに暗号化して引き渡す
　　→AADコネクトは認証情報を解号してドメコンに引き渡す
　　→ドメコンは認証結果をAADコネクトに返す
　　→AADコネクトは認証結果をAzureADへ返す
　③フェデレーション認証
　　ドメコンに参加しているPCから、「追加の認証情報入力なし（シームレス）」で
　　AzureADの認証をする場合はコレ。（…くそダルイ構成だな）
　　【前提１】ADFSとWebアプリケーションプロキシ(WAP)が必要
　　【前提２】ドメコン⇔AzureAD間はAzureADコネクトでディレクトリを同期している

　　（流れ）
　　ユーザはドメイン参加PCからサービス（例：Office365）へ接近する。
　　→Office365はADFSに認証トークンを要求
　　→ドメイン参加PCはADFSから認証トークンを受領
　　→ドメイン参加PCはWAPを経由してAzureADへトークンを連携
　　→AzureADはトークンを受領し、Office365アクセストークンを発行
　　→ユーザはOffice365へアクセスできる
・パスワードライトバック
　AzureAD側でパスワードを変更した場合、それをドメコン側にも反映させる。
　通常、同期方向はドメコン→AzureADだが、この機能をオンにしていると
　パスワードの変更だけは双方同期になるような感じ。（かな？）
・同期間隔
　最短で30分間隔。間隔は変更可能。
・同期内容のフィルタ
　AD情報で何を同期するかをフィルタできる。
　勤務地は連携しない、とか。通常はデフォルト設定で十分らしい。

3.所感

・他にも色々あったけど、AZ-103の枠から外れるので飛ばした。
・「AzureAD」だけで覚えることありすぎでしょ…
　Azureの試験範囲にいれないでよ…
　（Azureと密接な関係にあるのは分かるけど）
・ハイブリッド連携はなんとなく理解していたけど、良いおさらいになりました。

Azure Administratorへの道（5回：Load Balancer）

2020-12-26T13:01:33+09:00

Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900

ネットワーク周辺は業務でしっかりやったので概ね割愛。
ロードバランサだけ知識不足なため、そこだけは学習する。

0. スキルの評価対応

仮想ネットワークの構成と管理
　> Azure 負荷分散の実装

1. ロードバランサ（全体）

・Azureの負荷分散は大きく次の４つ
　①Public Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　インターネットに接している。（パブリックIPアドレスが必要）
　②Internal Load Balancer
　　OSI参照モデル4層（Tranceport層：TCP/UDP）の制御。
　　VNet内の制御。⇒パブリックIPは不要。
　③Application Gateway
　　OSI参照モデル7層（Application層）の制御。
　　SSLオフロードやWAF（WebApplicationFirewall）の機能もある。
　④Traffic Manager
　　OSI参照モデル7層（Application層）の制御。
　　厳密にはロードバランサではない。
　　DNSレベルでの地理的負荷分散（?）を行う。

2. パブリックロードバランサ

・SKUはBasicとStandardの２種類 : 詳細
　⇒機能差、性能差の面でStandardにすることが望ましい。
・バックエンドプール
　ロードバランサにより負荷分散している同一構成のマシン達のことを指す。
・正常性プルーブ(Health Probe)
　負荷分散対象のマシンのうち、どれが正常でどれが死んでいるかを検査する方法。
　プルーブ（Probe）は「調べる、精査する」の意味なので、「健康診断」くらい雑に訳しておくと覚えやすい。
・SNAT（送信元NAT）
　SNATの機能を持つ。（中から外へのNAT）
　DNATとSNATがよくわからなくなるので以下まとめを記載しておく。（我ながらへっぽこ）

SNAT はプライベートアドレスから発生した通信をグローバルアドレスに届ける技術。
プライベートアドレス(S)をグローバルアドレスに書き換えて通信を実現している。
ホームネットワークから外部サービスへの通信等がこれ。

DNAT はグローバルアドレスから発生した通信をプライベートアドレスに届ける技術。
グローバルアドレス(D)をプライベートアドレスに書き換えて実現している。
ホームネットワークで web/mail 等のサーバ等を複数台構築してアドレスを一つに見せて外部に公開する場合がこれ。

　引用元サイト
　他参考サイト

　この機能があるので、Load BalancerのNAT規則を整理すればバックエンドにいる任意のVMにRDPで接近できる。
　（3389ポートで接近した場合はVM1、3390ポートで接近した場合はVM2、みたいな制御）
　受信NAT規則（Inbound Nat Rule）として構成する。

　ちなみに、VM自体にパブリックIPがひもづけられている場合、SNATはしない。
　→VMに付いているパブリックIPでの通信を優先する。

・分散モード
　①ハッシュベースの分散モード
　　５要素（送信元IP、送信元ポート、あて先IP、あて先ポート、プロトコル）を元に
　　ハッシュ値を作成する。そのハッシュ値を元にバックエンドのVMへ分散していく。
　　→なので、クライントPCの利用ポートが変わるとあて先VMが変わったりする。
　②ソース IP アフィニティモード
　　２要素（送信元IP、あて先IP）を元にハッシュ値を作成し、その値を元に分散する。
　　①と違って、クライアントPCのIPアドレスが変わらない限りあて先VMは変わらない。
　　→処理途中で通信先VMが変わると困るこまる場合はこっち。
　　　リモートデスクトップゲートウェイの構成に使うそうな。

3. インターナルロードバランサ

・VNet内の負荷分散に使う。FrontEndにPublicロードバランサを置いてWEBアクセスを負荷分散している裏で、
　WEBサーバ→複数DBサーバへのアクセス負荷分散を実施するのに使う、など。
・Vnet内で使う、パブリックIPアドレスがない、などを除いて、基本パブリックロードバランサとできることは同じ。

4. Application Gateway

・Web Traffic load Balancer。（なので、WEBアクセスのトラフィック制御での利用しかできない）
・URLベースのルーティングができる。
　→例えばURLが
　　①https:\//xxx/imagesの場合、画像を保管するWEBサーバへ転送
　　②https:\//xxx/videosの場合、動画を保管するWEBサーバへ転送。
　　という制御ができる。（すごい）
・SSLオフロードの機能。
　→SSL/TLSのエンコード、デコードをサーバから肩代わり。
・複数サイトのホスティングへも対応。
　→http:\//contoso.comはcontosoサーバプールへ転送、http:\//fabrikam.comはfabrikamサーバプールへ転送、など。
・WAF（Web Application Firewall）の役割ができる。
　→Webサーバへのアクセスにおいて不正な通信内容
　　（SQLインジェクション、クロスサイトスクリプティングなどの恐れがある通信）を遮断する。

5. Traffic Manager

・「DNS ベースのトラフィックロードバランサー」
　というのが、どういうことか全然分からなかったけどこの図を見てやっと分かった。
　①クライアントがDNSサーバに問い合わせる。
　②DNSサーバはTraffic Managerへ問い合わせる。
　③Traffic Managerは定められた分散規則にしたがって、いずれかのエンドポイントのパブリックIPを返す。
　④取得したIPアドレスで直接エンドポイントへ接近する。
・この手法をとることで、地理的負荷分散もできる。
　→例えば、東日本リージョン、西日本リージョンにそれぞれWEBサーバを配置した構成も実現できる。
・分散方法（ルーティング方法）は次の通り。
　①優先順位
　　基本、プライマリサイトへアクセスさせ、障害時だけセカンダリを使うときはコレ。
　②重み付け
　　均等に分散したりするときはコレ。例えば、本番環境A、本番環境B、トライアル環境Cがある場合。
　　A:50、B:50、C:1としたときはAかBにアクセスし、Cにはアクセスしない。Aが障害時はBにアクセスする。
　　Cのトライアルが終了し、一般公開するときはCも50にするだけでよい。
　③パフォーマンス
　　地理冗長しているような構成のとき、「ユーザから最も近いエンドポイント」を指定させるときはコレ。
　　この後の「地理的」とはちょっと違う。こちらはあくまで「ネットワーク待ち時間」が最も短いルートをいく。
　④Geographic(地理的)
　　DNS クエリの発信元の地理的な場所に基づいて分散させるときはコレ。
　　アメリカ本社はUSリージョン、日本支社は東日本リージョンへアクセス！という使い方かな。
　⑤複数値
　　エンドポイントがオンプレしかない(IPv4、v6のアドレス指定しかない)場合につかう。
　　この場合、正常なエンドポイントのアドレスを全て返答してくる。
　⑥サブネット
　　クライアントのIPレンジによってアクセス先を変更したい場合はコレ。
　　x.y.a.0/24はA環境、x.y.b.0/24はB環境へ行け、ということができる。
・Azure（IaaS、PaaS）以外にオンプレミスのエンドポイントも指定できる。
・Traffic Managerのネスト（入れ子）もできる。
　この場合エンドポイントにTraffic Managerを指定する。
　→複雑。
・イントラ内では使えないのではないか？

「Traffic Manager のしくみ」で説明したとおり、Traffic Manager エンドポイントとして、Azure の内部または外部でホストされているインターネット接続サービスを指定することができます。したがって、Traffic Manager は、インターネットに接続されている一連のエンドポイントにパブリックインターネットからのトラフィックをルーティングすることができます。エンドポイントがプライベートネットワーク内にある場合 (内部バージョンの Azure Load Balancer など)、またはユーザーが内部ネットワークから DNS 要求を行う場合、Traffic Manager をこのトラフックのルーティングに使用することはできません。　

引用元

6. 所感

・「軽くさらっておこう」くらいの気持ちで始めたら、大分奥が深い。
・ApplicationGatewayとTrafficManagerの概要が理解できたのは良かった。（何にも分かってなかった）

Azure Administratorへの道（4回：仮想マシン）

2020-12-26T12:59:58+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-31 10:56:03 +0900

仮想マシン周りは概ね理解しているので、微妙に知識が足りないところだけ補足学習。

0. スキルの評価対応

仮想マシン（VM）のデプロイと管理

1. 仮想マシンの複数展開

1.1 イメージからの作成

イメージを作成するVMはSysprepを使う。
Linuxの場合waagent -deprovision+userでAzureのエージェントを初期化する。

1.2 ARMテンプレートでの展開

CopyオブジェクトやCopyIndexを利用するとよい。
複数の名前や値を生成できる。
例）次の場合、storage0、storage1、storage2の名前が生成される。
　名前
　"name": "[concat('storage', copyIndex())]",
　Copyオブジェクト
　　 "copy": { "name": "storagecopy", "count": 3 } 　
なお、ARMテンプレートの編集はVisual Studioで実施するとやりやすいらしい。

1.3 仮想マシンスケールセット

可用性セットとは別物。
この機能でVMを作成すると

すべての VM インスタンスが同一のベース OS イメージと構成から作成されます。
　というようにVMとして同一内容を保持した状態で自動スケールが実行できる。

基本、LoadBalancerを通してアクセスすることになる。
スケール方法は３つ
①手動
②スケジュール指定（スケールアウトするVM数も指定可能）
③メトリクス（CPU利用率など）の数値で自動スケールアウト

「え、すごい便利じゃん」と思ったが、下記情報あり。

※仮想マシン内にデータの保存はできますが、スケールインされるため、大切なデータは保存しない方が良いです。また、仮想マシン間でデータを共有する事もありません。

参考：https://www.cloudou.net/virtual-machine-scale-sets/vmss001/

…使えるケースが限られますね。（ログファイルとか消失するじゃん）
保存が必要なファイル（ログファイルなど）は別場所保管に設計すればいけるか。

2. 仮想マシン移行（オンプレミス to Azure）

2.1 Azure Site Rocovery

・実施前にDeploy Planner Toolを実行して情報収集をした方が良い。
　⇒ASR利用にあたるオンプレミスの情報がEXCELで出力される。
　　移行に必要な帯域幅や時間の情報を把握できる。
・構成サーバ、および移行元ホストはそれぞれHTTPSでAzureと通信し移行する。
　⇒443ポートで行うが、データ転送は9443ポートで行う。注意。
・Azure側ではリカバリーサービスコンテナ、ストレージアカウントが必要。

2.1.1 From Hyper-V

Hyper-VがSystem Center VMMで管理されている場合VMMが必要なケースあり。
移行元ホストにはAgentを導入する。
　

2.1.2 From Physical Server　

・構成サーバが必要。構成サーバがレプリケーション調整などを実施。
　⇒ちなみに構成サーバはSQL ServerでなくMySQLで稼動するらしい。
　⇒データ転送ポートを9443から変更することもできる模様。
・レプリケーション対象のサーバにはモビリティサービスエージェントを導入する。
・ASR自体はフェールバックも考慮したサービスだが、P2C移行になると
　フェールバックは難しい。物理サーバからの移行についてはP⇒Cへの一方向で考えたほうがよい。
　⇒ドキュメントを参照するかぎりできなくはないと思うが、あまり推奨しないということだろう。

2.1.3 From VMware

構成サーバーが必要。⇒OVFファイルがあるため、VMware上にデプロイするとよい。

2.2 Azure Migrate

・オンプレミスで稼働しているVMware上の仮想マシンを、Azureに移行した場合の
　「構成」や「費用」の確認ができるサービス（らしい）
・あくまでレポート情報を作成するだけであり、移行はASRで行う。
・VMware環境の情報収集に利用できる。（現在はHyper-Vも利用できる？）
　OVAファイル経由で収集用VMをデプロイし、収集結果をAzureへ送信し、その結果をレポートにまとめる、という流れか。
　（参考）https://www.cloudou.net/azure-migrate/mig001/

2.3 Data Migration Assistant

SQL Serverの移行などに利用。割愛。（おそらくAZ-103の範囲外）

2.4 ASRを利用しない移行

長期間のダウンタイムが許されるのであれば、下記方法もある。
①Hypre-VのVHDファイルをアップロードして使う
②Azure DataBoxでVHDファイルを移送して使う

3. カスタムスクリプト拡張、PowerShell DSC

Azureのカスタムスクリプト拡張機能と、DSCを使って、
デプロイした直後のVM 構成（エージェントやアプリ導入）を整理しましょう、という話のはず…（自信ない）

3.1 カスタムスクリプト拡張

・仮想マシンを作成したタイミングで、スクリプトを流せる機能。
・Win2008R2以上で利用可能。

3.2 PowerShell DSC拡張

・（Azureは直接関係ない）
・構成管理用の拡張機能。
・役割の有効化や環境変数の設定、ソフトウェアインストールなど構成に関することが色々できる。
・参考サイト：https://www.slideshare.net/kazukitakai/dsc-88799528

3.3 組み合わせてできること

・VMを作成した直後にウィルスソフトウェアインストール
・VM作成後のエージェント導入状態を同じくなるように管理
・その他いろいろ

4. 所感

・カスタムスクリプト拡張、PowerShell DSC あたりがPlurasightになかったので独学。
　⇒内容および範囲があっているのかどうか不安。
・ASRは業務で抑えていたのでおさらいレベル。
・スケールセットは可用性セットのことかな、と完全に勘違いをしていたので、把握できてよかった。

Azure Administratorへの道（３回：ストレージ関連）

2020-12-26T12:58:15+09:00

Qrunchからお引越しした記事です : created_at: 2019-08-24 15:55:30 +0900

備忘録的に覚えておきたい箇所を列挙メモ。

スキルの評価対応

ストレージの作成と管理

Azure バックアップの実装

・Recovery Service Vault ⇒　日本語だとリカバリーサービス「コンテナ」になる。
　（日本語もボルトに統一してくれよ…最初Valutって書かれていてピンとこなかったよ…）
・File単位のリストア
　⇒リストア結果をディスクとして一時マウントする仕組み。
・Azure Backup Agent（MARS：Microsoft Azure Recovery Services）
　オンプレ側のマシンに導入。ファイルなどのバックアップができる。
　こちらもリストア時は一時マウントになる。
・Azure Backup Server （MABS：Microsoft Azure Backup Server）
　MARSでカバーできない範囲をバックアップしたいときに導入が必要。
　マシン全体のバックアップやアプリケーションのバックアップなど。

ストレージアカウント

・レプリケーション
　LRS（ローカル冗長）、ZRS（ゾーン冗長）、GRS（地理冗長）に加えて、「RA-GRS」（読み取り可能な地理冗長）がある。
　GRSは通常、レプリケート先のサイトの情報はMSしかアクセスできない（MSが復旧処理するまで使えない）が、
　RA-GRSは平常時でもアクセス可能。
・アカウントの種類
　BLOB、Storage（V1）、StorageV2がある。
　①BLOB：BLOBしか使えない。
　②V1：ページ、キュー、テーブル、BLOB全部使える。クラシックのリソース管理用。
　③V2：ページ、キュー、テーブル、BLOB全部使える。リソースマネージャでの管理。
　通常、V2一択。
・アクセスキー
　このキーを渡すとストレージに対してフルアクセスできる。
　（何でもできるので取り扱い注意）
　キーの値はリフレッシュ（更新）でき、定期的な更新が推奨される。
・SAS：Shared Access Signature
　アクセスキーとは違い、アクセス内容を制限できるアクセス署名。
　読み取りのみ許可、アクセス元IPレンジの制限、プロトコルの制限、期間の制限、などなど。
・Stored Access Policy
　期間を決めてアクセス許可を設定できるポリシー。
　SASより大雑把なサービス（BLOB、キュー、テーブル、Files）レベルの制御。
・Azure Key Vault
　日本語だと「キーコンテナ」。
　色々なキーを管理するサービスだが、ストレージアカウントキーの自動管理もやろうと思えばできるらしい。
・AzureAD&RBACを利用したアクセス制御
　BLOBとキューのみ制御可能。
　AureAppServiceからストレージコンテナへのログファイル書き出し、などに有効。
　IAM制御にてAppServiceに対して必要なロールを割り当ててやればいい。
　（IAM制御でユーザだけでなくAppにも権限を割り当てできるのは初耳だった）
・暗号化
　デフォルトでMSのキーによって暗号化されている。
　独自のキーで暗号化することも可能。その場合、暗号化のキーをAzure Key Vaultで管理する必要がある。
・ネットワークアクセス
　デフォルトでインターネット上のどこからでも接近できる。
　設定変更によりアクセス可能なバプリックIPを指定したり、VNet内からアクセス可能にできる。
　⇒Vnet側のほうにもサービスエンドポイントの設定が必要。
・StorageExplorer
　ストレージの中身を参照するツール。Desktop版とWeb版があり、Web版はPortalから使える。
・診断ログ
　診断設定をオンにしている場合は「$logs」というBLOBコンテナにログが格納される。
　StorageExplorerでファイルを取得できるらしい（が、WEB版のStorageExplorerで参照しても該当コンテナが無かった）
　取得したログはMicrosoft Message Analyzerで解析すると見やすい。
・メトリック
　メトリックも診断設定をオンにしているとテーブルに出力される模様。
　メトリック情報からアラートを作成したりできる。

BLOB Storage

・ストレージアカウントのうち、「BLOB」に該当する箇所の補足追記。
・BLOBの形式は３種類。
　①Block Blob
　　複数ブロックに分けられたBLOB。ファイル追加、削除など普通に使う場合はこれ。4.7TBまで。
　②Append Blob
　　追加のみのBLOB。ログ保管など、ファイルの変更や削除をしない場合に使う。
　③Page Blob
　　VMのディスク（VHD）を置く。最大8TBまで。
・ストレージ層
　StorageV2のアカウントでのみサポート。次の３種類。
　①ホット：データ保存のコストが高く、データアクセスのコストが低い（頻繁に更新する場合に推奨）
　②クール：データ保存のコストが低く、データアクセスのコストが高い（保管メインの場合に推奨）
　③アーカイブ：最もデータ保存のコストが低いが、データ取り出しに数時間単位でかかる（長期保管用）
　※注意：ストレージ層を変更（移動）するとその移動量に対して課金される。（データアクセス分の課金がかかる）
　既定でホットにするかクールにするかをストレージアカウントで設定できる。
・コンテナ
　BLOBサービス内に無制限に作成できる。
　外部からのアクセスレベルを設定できる。
　①Private Access Level（デフォルト）
　　認証が必要。匿名アクセス不可。
　②Blob Access Level
　　BLOBへ読み取りアクセスはできるが、コンテナの内容をリスト化して閲覧することはできない。
　　⇒URLを知っている特定ファイルにしかアクセスできない
　③Container Access Level
　　指定のコンテナの内容をリスト化して閲覧できる。
・コンテナには不変ストレージの設定ができる。(WORM：Write Once Read Many　ともいう）
　この設定をするとアップロードしたデータの更新・削除ができない。
　⇒更新してはならないケース（金融、医療、法律、保険分野など）で利用する。
　一定期間は削除不可、またはホールド（Legal Hold）解除するまでは削除不可のどちらかを指定できる。
・Lifecycle Management
　ファイルのライフサイクルを指定できる。
　N日経過後にクール層へ移動、M日経過後にアーカイブ層へ移動、X日経過後に削除、のような指定ができる。
　⇒削除のポリシーはBLOBスナップショットごと削除してくれる。
・静的Webサイトホスティング
　有効にし、HTMLやCSS、Javascript、画像ファイルなどをアップロードするとWEBサイトとして使える。
　カスタムドメインの設定も可能。
・AzCopy
　BLOBにファイルをアップロードするコマンドラインツール。バッチ処理向き。
　どことなくrobocopyチック。指定オプションも沢山ある。
・ストレージ操作の.NETのライブラリもあるため、PGに組み込みで使える。
・Azure Search
　Azure Searchでストレージ内検索ができる。
　Azure Search自体はAzureのクラウド検索システム。
　前文検索的な動きをして、呼び出しもとに結果を返してくれる。
　プログラムに組み込んで使う。コグニティブのオプションで画像内検索とかもできるらしい。
　BLOB内のファイルにメタデータをつけていればメタデータでの検索も可能。

Azure CDN

・ユーザにコンテンツを分散して配信するサービス。（書いててもよく分からない…）
・BLOBストレージに置いて展開したいファイルへのアクセスについて、
　ユーザは世界中に存在するエッジサーバからファイルを取得できるようになる。
・なので「ゲームの新作トレーラーを0時に世界同時公開！」とかそういう時に利用することで、
　ユーザがすばやくアクセスできたり、中央サーバへの負荷やトラフィックが抑えられる、という感じか。
　（現状、業務で使うことはなさそうだな…）
・製品（価格帯）が４つある。
　Azure CDN Standard from Microsoft
　Azure CDN Standard from Akamai
　Azure CDN Standard from Verizon
　Azure CDN Premium from Verizon
・プロファイルを作成し、ストレージアカウントに割り当てる。
　その際にエンドポイント名称（グローバルで一意）を決める。
・CDNには次のURLでアクセスする。
　http://(EndpointName).azureedge.net/(myPublicContainer)/(BlobName)
・基本、CDNを使うときBLOBストレージのアクセスレベルはBLOBかContainer（外部アクセス可）である。
　これをPrivateのままにしたい場合はSASトークンを利用してアクセスする。
　この場合、URLの後ろにSASトークンを付与する。
・「URLの後ろにSASトークンつけると結局SASトークンが公開されていることになる！困る！」と言うときは
　「Premium from Verizon」であればURL書き換え機能で対応できる。
　これで、指定のURLにアクセスした際に自動でURL末尾にSASトークンを付与するようにできる。
・利用の際、CORS（クロスオリジンリソース共有）を考慮する必要があるらしい。（何だそれは…）
　通常下記の通りらしい。

クロスサイトスクリプティング攻撃の可能性を低減させるために、すべての最新の Web ブラウザーには
同一オリジンポリシーと呼ばれるセキュリティ制限が実装されています。
これにより、Web ページは他のドメイン内の API を呼び出すことができません。

　これをなんとかするための話らしい。

CORS (クロスオリジンリソース共有) は、あるドメインで実行されている Web アプリケーションが
別のドメイン内にあるリソースにアクセスできるようにする HTTP 機能です。

　CSNのCORSの欄で設定可能。

Azure Files

・ストレージアカウントのうち、「File」に該当する箇所の補足追記。
・SMBプロトコルを介してアクセスできるのがBLOBとの最大の違い。
　⇒ファイル共有をクライアントPCでマウントできる。
・ファイル共有で利用する場合、SMB（2.1 or 3.0）でやりとりする。3.0は通信が暗号化されている。
・クライアントが445ポート(SMB)が空いていてインターネットと疎通できないと使えない。
　⇒REST API経由でやりとりする分にはHTTPS(443)で通信できればよい。
　　なのでPowershell経由やCLI経由であれば443でいける。
・クライアントのOSがSMB3.0をサポートしていないと使えない。（Win8.1以降）
　⇒ストレージアカウントと同一リージョン内のAzure VMならWin2008R2でも接近できる模様。
　　（おそらく：同一リージョン内の通信はイントラ扱いになっているから○という感じか）
・AzureAD認証をサポート。
　…しているが、アクセスするにはクライアントマシンがAzureAD DomainService（AADDS）に参加している必要がある。
　また、ADDSドメイン（オンプレやVMのドメコン）に参加しているマシンはAADDSに参加できないため使えない。
　AADDSに参加できるのはAzureのマシンなので、オンプレにいるクライアントPCでも使えない。（使える範囲が狭すぎるよ…）
　⇒後述のAzure File Syncを使え、とのこと。
　⇒また、完全な管理者権限が必要な場合はアクセスキーでアクセスする。（AADDSで管理者権限を割り振っても完全でない）
・ファイル共有の最大割り当てサイズは5TBまで。（ストレージアカウント全体では500TB）
　最大ファイルサイズは1TB。
・スナップショットバックアップの取得が可能。
　取得している場合、ファイル共有でファイルのプロパティ「以前のバージョン」より過去ファイルの閲覧・取得が可能。
・AzureBackupを利用した定期的なスナップショット取得もできる。
　⇒1日1個までらしい。

Azure File Sync

・以下、参考サイト。
　https://cloud.nissho-ele.co.jp/blog/azure-file-sharing/
・Azure Filesとファイルサーバの内容を同期するサービス。
　ファイルサーバは複数台立てることができるため、複数のファイルサーバがAzure Filesを通してファイル内容を同期することができる。
・ファイルサーバを「サーバエンドポイント」、Azure Fileを「クラウドエンドポイント」と呼ぶ。
　１つの同期グループにおいて、クラウンドエンドポイントとサーバエンドポイントは1:Nの関係。
・Azure FilesのバックアップがAzureBackupでできるため、それをもってファイルバックアップとすることができる。
・障害発生時もAzure Filesからファイル復旧できる。
・実ファイルはFilesに保持させ、ファイルサーバ上ではポインタ（ショートカットのようなもの）のみ配置することもできる。
　これをすることによりファイルサーバのディスク容量を節約できる。
・ファイルサーバにエージェントを導入する必要がある。
・Azure File Syncはストレージアカウントと同一リージョンにデプロイする必要がある。
・同期で帯域を食う場合にはQoSをかけられる。（powershell経由）
・ファイルサーバはAzure Filesのファイル共有の要件（SMBのバージョン、ポート445解放）を満たす必要がある。
・ファイルサーバ側にファイルを置くと速やかにAzure Filesに連携される。
　が、Azure Filesに直接ファイルを置くとファイルサーバへの連携に1日かかることもある。（らしい）
・DFS名前空間と組み合わせて使うことができる。

インポートジョブ

・HDDの内容をBLOBコンテナに移動することができる。
・最初に、対象HDDをNTFSフォーマットした後、BitLockerで暗号化する。
・その後、waimportexportツールを使用し、インポート準備ファイル(jrnファイル)を作成する。
　⇒V1とV2がある。ストレージアカウントがStorageV1、V2の時はV2ツール、BLOBストレージの時はV1を使う。
　⇒V2では定義（対象ファイルやドライブ情報）などをCSVに記載して管理する。
　　Dataset用CSVに対象ファイルを列挙すれば、自動で対象HDDにファイルを収集してくれる。
・その後、AzurePortalからインポートジョブを作成。
　この際、作成したjrnファイルやインポート先のストレージアカウントを指定する。また、配送に関する情報もあわせて入力する。
・ジョブ作成後、ディスクを指定の住所に発送する。だいたいMSの準備が済むまで7～10日くらいかかる。（SLAはない）
　⇒すぐインポートしなければならない、という要件がある場合はマッチしない。
・発送後、追跡情報の更新（おそらく発送連絡）をする必要がある。
　これを2週間以内に実施しないと自動的にジョブがキャンセルになってしまう。
・到着後、自動的にストレージアカウント内にファイルが追加されている。

エクスポートジョブ

・Azureストレージの内容をHDDに移すことができる。
・まず、エクスポートジョブを作成する。（配送会社や住所の設定、対象ストレージアカウントの設定）
・NTFSフォーマットしたHDDを発送。
　⇒返送時はBitLockerで暗号化された状態で帰ってくる。
・インポートと同様に配送状況の更新は必須。
・届いたディスクを接続し、BitLockerのキーを入力しデータにアクセスできることを確認。

Azure Data Box

・こちらはAzure側でデータ格納デバイスを用意してくれるデータインポートサービス。
・注文⇒デバイスが届く⇒データを入れる⇒返送⇒データが反映される

所感

・全然業務で使わないような箇所も勉強できて、いい機会にはなった。
・ストレージアカウント周辺は「なんとなく」から「ややしっかり」の理解になった。よかった。
・インポート、エクスポート、DataBoxは仕組みを把握しておくと将来役に立つ日がくるかもしれない。
・Filesは便利だけど使う日がくるかな…
・CDNはたぶう使う日はこない。（転職か異動がないかぎり）

Azure Administratorへの道（２回：Azure MFA）

2020-12-26T12:56:04+09:00

Qrunchからお引越しした記事です : created_at: 2019-07-13 16:30:22 +0900

スキルの評価対応

アイデンティティの管理
　> Multi-Factor Authentication (MFA) の実装

MFAとは

Multi-Factor Authentication
多要素認証のこと。

「アカウント + パスワード」より強固なセキュリティを担保しないといけない時に使う。

適用範囲

AzureのSaaS
AzureのPaaS
AzureのIaaS上に構築したアプリケーション
Azureとつながっているオンプレミス上のアプリケーション
Office 365

などなど

認証方法

電話
電話がかかってくるので、それに出て「#」をプッシュ。
PINの入力を要求するモードもあり。
SMS
1Way：SMSで通知したパスワードを画面に入力。
2Way：SMSでパスワードが通知されるので、同じ番号をSMSで返答する。
どちらもPINコードの追記を要求するモードあり。
アプリ認証
MSのアプリを起動して、アプリから認証する。
PINコードの追記を要求するモードあり。
OATH
MSのアプリから発行されるセキュリティトークン（6桁数字）を求められる。
MSのアプリでないOATHトークンアプリ（Googleのやつとか）でも利用できる。

認証情報の保管

Azure Active Directoryに保管。なのでAADがある環境が前提。

MFA Server

・認証方法によっては必要。
・オンプレミス上のアプリからMFAを利用する際に必要？
・オンプレミス上のサーバに構築する。
・オンプレミスのADやLDAPなどとユーザ情報を同期できる。
　AzureMFA⇔MFA Server⇔オンプレのドメコン
・複数台構築し、内容を同期することが可能。
　⇒冗長性担保。
・ドメコンにインストールするのは不可。

所感、感想

・多要素認証。7 Payの事件で一躍有名になったね。
・今の仕事だと使わなそうだなー。
・銀行系（ネットバンキング）とかだと必須ですね。