こちらの内容についてMicrosoft社のAzureドキュメントを見ながら勉強し理解した内容を共有する。
Microsoft社の資格は取得後も１〜２年での更新が必要。仕事で頻繁に使用していないと知識を維持することは難しいので、自分の知識をまとめて後で振り返れるようにしておくことはとても重要。
この記事をサクッと読んでからMicrosoft社のドキュメントを読むと少し理解が早いかもしれない。（逆に混乱したらすみません）
昔の日本語ドキュメントサイトに比べて最近は本当に改善されて読みやすくなったので、もっと深く理解したいと思った方は記事途中に参照リンクを貼っておくのでそちらを参照されたし。
Azure ADの認証に関する機能
セキュリティ強化、およびヘルプデスクのサポート負荷軽減のために利用できるAzure ADの機能で以下のような機能を有する。
- セルフサービス・パスワードリセット
- MFA
- パスワードの変更をオンプレADに書き戻すハイブリッド統合
- パスワードの保護ポリシーをオンプレADにも適用するハイブリッド統合
- パスワードレス認証
FIDO2によるパスワードレス認証
FIDO２とパスワードレスの認証方法
一般的なパスワード認証はセキュリティ的にいけてないため、よりセキュアな方法で補完する必要がある。
安全性、ユーザーからみた利用しやすさ、適用可能なデバイスの多さなどの観点でメリットのある選択肢の一つとしてFIDO2がある。FIDO2はWindows, Android,そのた主要なブラウザで利用できるパスワードレスの認証方式を提供する。FIDO2ではUSBデバイス、Bluetooth、NFCをセキュリティキーとして利用できるが、WebAuthnに対応したブラウザでも利用できる。
Azure ADではFIDE2が利用できる。
FIDO2とは何かを正しく理解する
Azure ADのセキュリティ設定でFIDO2を有効化し、FIDO２認証を利用する対象ユーザーを選択するか、全ユーザーを対象にすることもできる。
対象となったユーザーは「https://myprofile.microsoft.com/」にて自分のFIDO２セキュリティキーを登録する必要がある。
Windows Hello for Business
Windows Helloの仕組みを理解する
MSのドキュメントを基に頑張って私の理解をまとめたが、イマイチ分かりづらいかもしれない。
- Windows Helloは、パスワード認証を非対称キーをベースにした認証に置き換える
- パスワード認証はWindows Hello 資格情報を登録する時に１度だけ行われ、その時に非対称キーのうちの公開キーがサーバーに登録される
- 一度Windows Hello資格情報が登録された後は、パスワード認証は実施されず、秘密キーによるトークンの暗号化／サーバー側ではユーザーアカウントに紐づく公開キーでの暗号化トークンの復号によりユーザーを認証する
- ローカルデバイス側のキー（秘密キー）はTPMというハードウェア的に保護されているモジュール（ハードウェアチップ）で管理され、認証時にユーザーが入力するPINもしくは生体認証（ドキュメントでは「ジェスチャー」と呼ばれている）によりアクセスできる場所に保管されている
- ユーザーが入力するPINもしくは生体情報はデバイスにもサーバー側にも保存されず、デバイス間でやりとりされることもない（ほんとに保存していない事をどうやって保証できるのか？）
MSのドキュメントでは、他にも「単一のコンテナーをキーにする」とか「全てのキーはIDPのドメインで分離される」とかの表現で説明されているが、これが何を意味するのか全く理解できなかったので上記には含めておらず。。
Azure AD Connectによるハイブリッド環境下におけるWindows Helloでは特別なセキュリティグループが必要
「KeyCredential Admins」セキュリティグループ
Azure AD Connectによる同期を行なっているハイブリッド環境では、オンプレADに「KeyCredential Admins」というセキュリティグループが必要となる。
Azure AD Connectでは、この名前のセキュリティグループに対してAD属性の読み込み／書き込み権限を割り当て、同期処理の一環としてオンプレADのユーザーオブジェクトに紐づいている公開キー情報をAzure ADに同期する。
「Windows Hello for Business Users」セキュリティグループ
このセキュリティグループに登録されているユーザーに対してWindows Hello for Businessを設定するために必要な権限（認証証明書の登録をするための適切なアクセス許可）が付与される。
逆にこのセキュリティグループに登録されていないユーザーは Windows Hello for Businessを構成することができない。
Windows Hello for Businessのポリシーを構成する
TPMとは
「Trusted Platform Module」の略で、資格情報、ユーザーID、暗号化キー、個人情報などを保護するためのハードウェアチップのこと。
今までは、CPUとTPMは別チップとして構成されていたため、攻撃者は物理的な手法でTPMからの機微情報を取得することを試みているが、最新のチップでは、TPMがCPUに内包され物理的な攻撃からも保護されるように構成された「Pluton」と呼ばれるセキュリティプロセッサが開発されているらしい。
セルフサービスパスワードリセット（SSPR）を構成する
セルフサービスパスワードリセット（SSPR）を構成することで、ユーザーがパスワードを忘れた場合の再登録をユーザー自身で実行できるようにする。
これにより、Azure AD管理者の手間が省けるし、ユーザーもいちいち管理者に問い合わせする必要もなくなる。
すごく単純な機能だが、管理者の立場からすると必須の機能だろうから組織で利用する場合は必須で有効化しておいた方がいいだろうな。
Azure AD Premium P1 or P2が必須
この機能を利用するためには以下の有償ライセンスが必要となる。
- Azure AD Premium P1
- Azure AD Premium P2
- Microsoft 365 Businessプラン
有効にする手順
もし全てのユーザーに対してSSPRを有効にする場合は、Azure AD の「パスワードリセット」で「セルフサービスによるパスワードリセットが有効」で「すべて」を選択すれば良い。
特定のグループだけ有効にした場合は「セルフサービスによるパスワードリセットが有効」で「選択済み」を選択し、グループを選択すればよい。
※以下の画面イメージにある通り、私のアカウントではPremiumライセンスがないため、詳細が確認できない。。。(期間限定の評価版ってなかなか使う気になれない。。)
オンプレADパスワード保護のデプロイ
Azure ADのパスワード保護機能を用いて、オンプレADのユーザーに登録されているパスワードポリシーをAzure ADのパスワードポリシーで置き換えることができる。
そのためには既存のオンプレADDC環境に対してAzure ADパスワード保護コンポーネントをインストールし、パスワードポリシーをAzure ADのパスワードポリシーと同期させることが必要。
必要な構成
- Azure ADパスワード保護プロキシサービス（別サーバーを準備）
- Azure ADパスワード保護DCエージェントサービス（DCサーバーへインストール）
特徴
- DCサーバーがインターネットと直接通信することはない
- DCからの新しい受信ポートのオープンは不要
- DCスキーマは変更されない
- 追加のアカウントも不要
- Azure ADとの同期方式にも影響しない（ハッシュ同期でもWriteバックでも影響なし）
- 読み取り専用DCにはエージェントサービスは不要（これらの要求イベントは書き込み可能なDCに転送される）
デプロイ要件
- DCサーバーからAzure ADパスワード保護プロキシサービスへの135ポートへの接続が必要
- 複数フォレストで構成されている場合、各フォレストで設定する必要がある
- フォレストルートドメインのADドメイン管理者権限アカウントが必要
- Azure ADパスワード保護プロキシサービスは以下のエンドポイントへのアクセスが必要
DCエージェントサービス固有のデプロイ要件
- OSはWindows Server 2012以降
- .NET 4.5が必要
- 各DCエージェントサービスのsysvolレプリケーションには分散ファイルレプリケーションを使用
Azure ADパスワード保護プロキシサービス固有のデプロイ要件
- OSはWindows Server 2012 R2以降
- .NET 4.7が必要
- DCに対して、プロキシサービスへのログオンを許可するように構成する必要がある
- プロキシサービスがホストされているサーバーで、TLS1.2 http送信トラフィックを許可する
- フォレストの全体管理者またはセキュリティ管理者権限のアカウントが必要
- Azure ADアプリケーションプロキシとは別サーバーに構築する必要がある
同期された後のオンプレADのパスワードポリシー
同期されるとAzure ADパスワードポリシーはDCサーバーのSysvolフォルダーに格納され、パスワード更新処理時にはそこに保存されたポシリーが参照される。
ただし以下の制限がある
- 既にパスワードが設定されたユーザーのパスワードは変更タイミングまでそのまま運用される
- パスワードを無期限にしているユーザーには適用されない
パスワード保護プロキシサーバーの可用性
２つのプロキシサーバーがあれば十分。
- DCエージェントサービスは単純なラウンドロビン方式でプロキシサーバーにリクエストを送信する
- リクエストに応答しないサーバーはスキップされる
- DCエージェントサービスはダウンロードした保護ポリシーをキャッシュする
- パスワードポリシーの同期処理は通常日単位
このため、短時間のプロキシサーバー停止があってもパスワード保護自体への大きな影響はない。
必要に応じて、プロキシサーバーは追加できるので要件に応じて追加すればよい。
「テナント制限」という機能を実装
OutlookやM365といった共有SaaSアプリケーションを使用する場合、ユーザーアカウントが所属する「テナント」が存在し、ユーザーアカウントはそのテナントに紐づく。
企業ユースの場合、特定のテナントへのアクセスを許可し、他のテナントへのアクセスを禁止したい場合があるが、そのような場合にこの制限機能を利用できる。
テナント制限について
我々のような、自分の組織用のM365テナントとアカウントがあり、複数の顧客企業と協業して顧客テナントへのゲストアカウントとして登録してもらうようなケースの場合は、多分利用しないのかな。
自分の組織のテナントだけで仕事ができるケースであれば、この機能を利用することで誤ったテナントへのデータアップロードなどを防ぐことができる等のセキュリティ的なリスクが軽減するということなのかな。
この機能の用途が少し見えづらい。
オンプレのプロキシサーバーの役割
この機能を利用するためにはオンプレ側にプロキシサーバーが必須となる。
- オンプレ環境から共有SaaSにアクセスした際に、認証リダイレクト時のAzure ADへアクセスする
- Azure ADでは、HTTPリクエストヘッダーに含まれる以下２つのキーを参照して、アクセス要求のあったテナントへのアクセスが許可できるかどうかをチェックする
- Restrict-access-to-tenants：アクセス許可ドメイン名リスト（アクセスして良いテナントリスト）
- Restrict-access-context：アクセス制限をしているAzure ADのテナントID（ユーザー所属テナント）
- HTTPリクエストヘッダーはプロキシサーバーで設定する
条件
- クライアント側で先進認証（OAuth2.0など）を利用できることが必須
- オンプレ側にTLSインターセプト、HTTPヘッダー挿入、FQDN/URLを使用した送信先フィルター機能があるプロキシサーバーが必須
- Azure AD Premium P1ライセンスが必須
今後の課題：アプリケーションでこれらの設定が行われたアカウントに対する認証を実施する方法
仕組みや設定方法は（一部を除いて）理解できたが、これらを活用したアプリケーションを作ってみたいという思いがあり、今後Node.jsもしくはJavaでAzure AD認証を用いたWebアプリケーション、ネイティブアプリケーションによるユーザー認証、および、Azure ADで保護されたAPIに対するサーバーレスアプリケーションからのアクセスなどの実装にチャレンジしてみる。
もちろん無料枠で。
コメント