[Azure] Azure Active Directory についてまとめてみた
学習資材
Azure ADのエディション
Free・Apps・P1・P2が存在する。
Freeだと、ユーザやグループの管理、SaaSへのSSOアクセスなど、基本的な操作のみになる。
P1とP2の違いは、Identity Protection(後述）とPrivileged Identity Management (PIM)(後述）がP2では提供される。
詳細は以下の通り。
Identity Protectionとは
その名の通り、ID保護に関するサービス。IDベースで、リスクの検出/管理/保護を行ってくれるサービスと考えればよい。
機械学習を使って、例えば、接続元IPアドレスを隠蔽してアクセスしてきた通信をブロックするといった保護ができる。
詳細は以下の通り。
- 脅威に対しての自己修復/管理者修復のフローの違いのイメージ。
以下の図が参考になった。自己修復とはいっても、脅威をAzure側で完全に排除するのではなく、あくまでアクションを自動的にユーザに促すというのが正しいのだろう。
サインインリスクポリシーとユーザーリスクポリシーの違い
以下の記事がサポート執筆でありわかりやすい。
簡単に言うと、前者はリアルタイムのリスク（アクセス元の IP アドレスを隠してアクセス）を検出し、後者はオフラインのリスク（ダークウェブをチェックしてユーザ情報が漏洩していないかを監視）を検出する。
検出後は、「ブロック」か「MFA要求」（サインインリスク）か「パスワードリセット」（ユーザーリスク）を実施できる。
設定する閾値レベルについて
毎回悩みどころになる、閾値の問題。
マイクロソフトとしては、ユーザーリスクの閾値は「高」・サインインリスクの閾値は「中以上」を設定することを推奨している。あくまで推奨値なので、セキュリティに重きを置く場合は、多少運用が面倒になっても閾値を低めに設定するのがよいのだろう。
Azure ADとAD DSの違い
どちらもActivie Directoryになるのだが、全く同じものではない。
AD DSはWindows Serverにデプロイして、オンプレミスドメインの（認証）管理を行うことが目的となる。一方位で、Azure ADの場合は、SaaSのID管理としてクラウドベースの（認証）管理を行うことが目的となる。それに伴い、細かい機能差分も発生する（グループや認証方法など）
AD DSだが、Azure で提供されている、Azure AD DSというサービスも存在する。
Azure AD DSの使いどころ
例えば、Vnet上にIaaSを作成してドメインに参加させたい時である。AD Connectというサービスを使うと、オンプレのAD DS⇔Azure ADで同期を図り、ADに同期した内容をAzure AD DSにも同期さることができる。
こうすることで、オンプレとクラウド上において、同じID・パスワードを使うことができるようになる。
(IaaSを太字にしたのは、Azure ADのSaaSとの差分を強調するためである）
Azure AD グループへのユーザの追加
まず前提として、グループ単位で権限の割り当てができる。（運用効率化）
動的メンバーシップルールを利用することで、ユーザ/デバイスがルールに従っているかを自動的に確認し、ユーザ/デバイスの追加・削除が可能になる。便利な機能が存在する。
また、グループのメンバーとしてグループを追加することも可能である。その際の制約として、割り当て済みグループには動的グループを追加できるが、その逆は不可能である。動的グループなので、ユーザが選択して追加するのはできないということ。また、Microsoft365グループはメンバにユーザしか追加できない。
セキュリティグループ：アプリケーションやリソースへのアクセスを付与したり、ライセンスの割り当てを行うために作成される。M365系のライセンスは割り当て不可と考えていたが、任意のライセンスが割り当て可能である。動的グループ・割り当てグループは特に関係ない。
Microsoft365グループ：sharepointやteams、Plannerといった社内外コミュニケーション用に作成される。
セキュリティグループは一度削除すると復元することができないので注意。M365グループは30日間は復元が可能
Azure AD の管理単位機能とは？
「管理単位」という機能を使うことで、特定のグループ/ユーザに対して、ADに所属するユーザの管理を委任することができる。
グループ・ユーザに対して、用途に応じた管理者権限を付与し運用していくことになる。
Azure ADの動的グループについて
動的ユーザと動的デバイスはグループの種類が異なる。そのため、両者を動的グループのメンバにしようとした場合は、大元のグループを1つ作り、その中に2つのグループを追加する運用が必要になる。
AADとAADDSとADDSの違い
超絶ざっくり
Azu AD アプリケーションプロキシとは？
オンプレにあるアプリケーションを、セキュアに外部に公開するためのAzureADの仕組み。
Azure AD を使った認証
という風に聞くと、ADレベルでのロール（グローバル管理者とか）での認証と思い込み、いやいやAzureリソースへのロールとは違うのだよ！となっていた。
実際はAzure ADでの認証とは、Azure RABC、すなわちサブスクリプションレベルでのRBACも含まれる。変に知識をつけると誤解が生まれるな。。。
オンプレ AD アプリ登録 SAML
必要？ ＝＞ 認証で必要そう。
SAMLのメタデータをお互いに交換して信頼関係にする…というのが該当するのかな。
BOXとかSaaSアプリじゃなくても、オンプレにある場合でも、SAMLメタデータを交換して信頼関係を結んでおくことで、認証はAzureADに飛ばすことができるといった感じか。
アプリケーションへの委任されたアクセス許可とは。
次の一枚絵がすごく簡潔になっている。
ユーザが明確にログインして、そのユーザの権限を使ってアプリケーションが操作する場合は、委任されたアクセス許可。
逆に非対話でバックグラウンドで動いているようなアプリは、アプリケーションのアクセス許可になる。
Azure AD リダイレクトURI トークン応答
リダイレクトURIとは、Azure ADでの認証後にリダイレクトするURIのこと。良くあるのは、Azure AD認証前の画面をしているするとか。
OAuthは以下が分かりやすい
SAMLとOAauthの違い
前者は認証、後者は認可を行うという違いがある。
なので、SAMLは認証が通った後の動きは、割り当てられたロールに従うのだろう。
外部ユーザに対するAzure AD ID プロバイダーとは
前提としてID プロバイダーでは、ユーザIDの作成・保守・管理、アプリケーションへの認証を行ってくれる。Azureでは既定のIDプロバイダーとして、外部ユーザに対してAzureADになっている。
それ以外には例えば、FacebookやGoogleが存在する。
Azure AD の「セキュリティの既定値群」でできること
- 誰向け？
Azure AD Freeライセンスを使っている or セキュリティ対策をしたいがすぐには整理できない人向け - 何ができる？
- 全てのユーザにMFAの登録を要求する
- 管理者ユーザにMFAの実行を要求する
- レガシー認証をブロックする
- 必要に応じて（悪意のあるアクセス）ユーザにMFAの実行を要求する
といったことが可能になる。登録の要求と実行の要求は文言の通り。何かあった時に実行するために登録だけ要求するパターンと、常に実行が要求されるパターンである。
多要素認証について
Azure AD MFA 登録ポリシーについて
ユーザにMFA登録を強制させる方法の１つ。他には、Azure ADでセキュリティの既定値群をオンにすることでも可能になる。
Microsoft Defender for Identityについて
そもそも何か
オンプレ環境のADにおいて、高度な脅威・侵害されたID（レポートによる検出など）・悪意のある内部関係者のアクションを識別・検出・調査するためのサービスである。Azure ADのIdentiry Procectionと組み合わせてハイブリッドクラウド環境でのユーザ保護を実現できる。
エージェントをオンプレに導入する必要はありそうである。
Microsoft Defender for Cloud Appsについて
クラウドアクセスセキュリティブローカー(CASB) である。CASBとはユーザとクラウドサービスプロバイダーの間に置かれ、クラウドサービスの利用状況を可視化できるセキュリティサービスである。他の代表的なサービスとしてnetskopeが存在する。
Cloud Discoveryについて
様々なクラウドサービスが存在する中で、利用者が使っていいクラウドサービスかどうかをスコアリングして制御するための昨日である。
「エンタープライズアプリ」と「アプリの登録」の違い
ともにアプリとして、AzureADの左ペインに存在するが、何が違うのかが気になった。
結論としては以下の記事に記載がある。
エンタープライズアプリ：既存のSaaSアプリ（オンプレで提供しているアプリ含む）を公開するとき
アプリの登録：新規で開発するアプリを公開するとき。
登録したアプリのプロパティ
ユーザの割り当てが必要ですか？は、枕詞に「アプリへのサインインには」とつけるとなお良い。ユーザへの表示には、この項目でのはい・いいえは影響しない。「ユーザに表示しますか？」でのはい・いいえではいを選んだ時には、そもそもの前提として割り当てが必要になるというイメージである。
セルフサービスアプリケーション
ユーザがマイアプリポータルから、自分でアプリケーションを見つけられるようにすること。これによって、都度依頼をせずに必要なアプリを自分で見つけられるようになったり、事前にユーザにグループを設定することでアプリ利用に必要なロールの管理を行うこともできる。
アプリケーションへの「同意」をすることで実現できること。
MS Learnの記事を読んでいてもよくわからなかったので、以下の記事が一番わかりやすい。
同意をすることによって、アプリケーションへの権限の委任を行うことができる訳である。ただ、アプリによっては一般ユーザの同意ではなく、管理者の同意が必要になる場合もある。
上記は、ユーザの権限を委任する場合だが、アプリケーションそのものに権限を付与するケースも存在する。前者の場合は、ユーザが参照可能な範囲のリソースしか操作できないが、後者の場合は場合によってはテナント全体のリソースにもアクセスが可能になる。
エンタイトルメント管理とは
アプリケーションへの資格の付与を管理する機能のこと。サブスクリプションへの資格付与やAzure ADの資格付与など、資格付与の考え方は他にもあるがその1つ。
アクセスパッケージとは
エンタイトルメントで導入されている概念。ユーザが作業を実施するために必要なアクセス対象のリソースとそのアクセス権をバインドしたひとまとまりのパッケージ。このパッケージ単位でアクセスを許可していく。
Azure Active Directory のパスワードを保護するためのカスタムの禁止パスワード
類似文字（数字の０とアルファベットのO）も判断される。
Azure AD のセルフサービスパスワードリセット
モバイルアプリの通知は、必要な方法の数が2つの時にしか選択できない。
ネットワークポリシーサーバ
オンプレのクライアントやVPNクライアントにAzure ADベースの多要素認証を実装するための、オンプレとクラウドの間に入ってやり取り」してくれるサーバ
MFA認証の推奨
SMSやOTPよりも、FIDO2セキュリティキーが推奨される。
条件付きアクセスポリシーの事前確認
レポート専用モードを利用することで、エンドユーザへの影響を見極めることができる。
フォールバックレビュー担当者
グループに所有者がいないときにレビューを割り当てられる人
Azure AD 緊急アカウントの要件について
資格情報の有効期限が切れておらず、使用不足による自動クリーンアップの対象になっていないこと
Discussion