プロに教わるAzure設計運用のベストプラクティス 第5回

AzureでのIAMの考え方と実装をサポートするフレームワーク／Azure ADの機能／サービス群

Azureにおける「IDとアクセス管理」のベストプラクティス

Well-Architected FrameworkとAzure Security Benchmark

　より実践的に対応していくためには、Well-Architected Framework（以降、W-AF）のセキュリティの柱にある「AzureのID管理とアクセス制御セキュリティのベストプラクティス」などが参考になる。

Well-Architected Frameworkにおけるセキュリティ領域のデザイン項目

　W-AFのセキュリティにおけるIDとアクセス管理のベストプラクティスには、次のような項目がある。

・IDを主要なセキュリティ境界として扱う
・ID管理を一元化する
・接続済みテナントを管理する
・シングルサインオンの有効化
・条件付きアクセスをオンにする
・日常的なセキュリティ強化を計画する
・パスワード管理を有効にする
・ユーザーに多要素認証を適用する
・ロールベースのアクセス制御を使用する
・特権アカウントの公開時間を短縮する
・リソースが配置される場所を制御する
・ストレージの認証にAzure ADを使用する

　これらの原則に基づいて実装を考えると、ほとんどがAzure ADの機能を用いたものになる。逆に言えば、こうした原則を満たすために必要な機能を備えるべく、Azure ADが機能拡充を続けてきたという関係にある。

　情報量の都合上、本稿ではこうした原則やデザインのすべてには触れられない。だが、W-AFのベストプラクティスは利用者の利用状況に応じて活用しやすく、非常に役立つためぜひ参照していただきたいと思う。詳細は、本稿末尾に掲載してある「参考情報」のリンクからアクセスできる。

　とは言えそれだけでは乱暴なので、ここでは粒度も適切で、バランスの良い入り口として「Azure Security Benchmark（以降、ASB）」をご紹介させていただきたい。

●Azure Security Benchmarkに沿ったIDおよびアクセス管理の考え方

　ASBは、Azure上のワークロード、データ、およびサービスのセキュリティを向上させるのに役立つ、規範的なベストプラクティスと推奨事項を提供するものである。CIS Controls v7.1やNIST SP 800-53 r4といった業界標準のベンチマークに沿った形となっており、前述したCAFや、特にW-AFにおける内容をセキュリティ面で包含している。要するにW-AFのベストプラクティスにも沿ったものとなっている。

　ASBでは「考え方（コントロール）」と「Azure上での実現方法（ベンチマーク、ベースライン）」が対になる形で構成されているため、わかりやすい。これにより、概念的なベストプラクティスとAzureのサービスを含む推奨事項の双方をカバーしている。

コントロール、ベンチマーク、ベースライン

●ID管理のコントロールと、Azure ADなどで利用できる機能

　ASBには11個のコントロールドメインがある。そのうちの2つ、「ID管理（IM）」と「特権アクセス（PA）」が本稿のテーマに関連するものだ。例えばIMコントロールドメインは、次のような項目で構成されている。

ASBにおけるID管理（IM）のコントロール

　Azure ADはこれらに対応する機能を多く備えており、大ざっぱに言えば、まずはAzure ADの各種機能を用いることがバランスの取れた対応につながる。

　ここからは、そうしたIMドメインのベンチマークに出てくる各種機能を紹介したい。前述したとおり、これらはリスクへの対応として利用し、正しく運用することが大切であり、個々の機能を利用しさえすれば万事解決という話“ではない”ことにご注意いただきたい。ASBにおけるコントロールの概念を参照したうえで、適切に利用してほしい。

・IDセキュリティスコア：
　これはIMのコントロール全体にかかわる機能だ。

　Azure ADでは、Microsoftのベストプラクティスにおける推奨事項を参照して、現在のIDセキュリティ構成に対してスコアリングを行う「IDセキュアスコア」の機能を持つ。例えば改善事項が多いほど、スコアが低くなるわけだ。現在の構成がベストプラクティスの推奨事項にどの程度一致しているかを評価し、セキュリティ体制を改善することができる。下の画面は非常に悪い例である。

IDセキュリティスコアの画面

・マネージドID：
　これはIM-2のような、アプリケーションのID管理のリスク対応に関わるものだ。

　AzureマネージドIDは、Azure AD認証をサポートするAzureサービス／リソースを、ユーザーにひも付かないアプリケーションや自動化のためのアカウントで認証／利用できる機能である。認証は事前定義されたアクセス許可ルールによって有効になり、ソースコードや構成ファイルに資格情報をハードコードせずに済む。

　このマネージドIDを使うことができない理由がある場合は、リソースレベルでアクセス許可が制限されたサービスプリンシパルを作成して利用する。こちらはIDとアクセスの管理機能をAzure ADに委任するために、アプリケーションをAzure ADのテナントに登録するという考え方だ。

　どちらの場合も、シークレットを管理するAzure Key VaultをAzure マネージドIDと組み合わせて使用でき、ランタイム環境（Azure Functionsなど）もKey Vaultから資格情報を取得できる。

・条件付きアクセスなどのアクセス制御：
　これはIM-4のように認証制御をより強化する考え方だ。例えば多要素認証（Azure AD Multi-Factor Authentication：MFA）を用い、またAzure Security Centerの「Enable MFA」セキュリティコントロールの推奨事項に従い管理を行う。MFAは、すべてのユーザー、一部のユーザー、またはサインイン条件とリスク要因に基づいてユーザーごとのレベルで適用することができる。これはAzure ADの条件付きアクセスで求められるアクションとして定義することもできる。

　今回の文脈とは異なるが、パスワードなしの認証であるWindows Hello for Business、Microsoft Authenticatorアプリ、スマートカードといった、3つのパスワードなしオンプレミス認証オプションもこのコントロールに含まれる。

・シングルサインオン（SSO）：
　IM-3に限らず、シングルサインオン（SSO）が求められるシチュエーションは多い。Azure ADシングルサインオンを使用することで、オンプレミスおよびクラウド内の組織のデータとリソースへのアクセスを管理および保護することができる。すべてのユーザー、アプリケーション、およびデバイスをAzure ADに接続して、シームレスで安全なアクセスを実現することも可能だ。

・クレデンシャルの検出：
　IM-7など、アプリケーションコードや設定ファイルにハードコードされたクレデンシャルを検出し、パスワードなどが漏洩するリスクを防ぐ対応事項だ。

　Azure DevOps Credential Scannerを実装することで、コード内の資格情報を検出することができる。さらにCredential Scanneは、検出されたクレデンシャルをAzure Key Vaultなどの安全な場所に移動することも推奨する。

　またGitHubでは、ネイティブシークレットスキャン機能を使用して、コード内のクレデンシャルやその他形式のシークレットを検出することもできる。

・Azure AD Application Proxy：
　IM-8のような、オンプレミスにあるレガシーアプリケーションへの対応も重要だ。レガシーアプリケーションをAzure ADとVPN接続する方法で対処することも可能だが、その場合はシンプルな認証履歴しか残らない場合が多い。

　ここでAzure ADアプリケーションプロキシを利用すると、レガシーなオンプレミスアプリケーションをSSOでリモートユーザーに公開し、さらにAzure AD条件付きアクセスを使用してユーザー／デバイスの両方に信頼性の検証を加えることができる。

　別の方法として、CASB（クラウドアクセスセキュリティブローカー）であるMicrosoft Cloud App Securityを利用して、ユーザーのアプリケーションセッションを監視し、不審なアクションをブロックすることも可能だ。

・モニタリング機能：
　IM-5で明記されているとおり、ID利用状況の継続的な監視は必要だ。Azure ADでは以下のような機能が有効活用できるだろう。

・サインインレポートを用いて、管理対象アプリケーションの使用状況とユーザーのサインインアクティビティに関する情報を取得する。「誰が」「何に」「いつ」「どこから」アクセスし、結果どうなったのか把握する。

・監査ログを用いて、Azure ADのさまざまな機能を通じて行われたすべての変更を取得する。「誰が」「何に」「いつ」「どのオブジェクトを」変更したか把握する。

・危険なサインインの情報から、ユーザーアカウントの正当な所有者ではない誰かによって実行された可能性のあるサインインを把握する。

・危険なユーザーの情報から、侵害された可能性のあるユーザーアカウントを把握する。

・Azure Security Centerで、認証試行の失敗回数が多すぎるアカウント、サブスクリプション内の非推奨のアカウントなど、特定の疑わしいアクティビティをアラートする。

・Microsoft Defender for Identity（旧 Azure ATP）を用いて、オンプレミスのActive Directoryシグナルを利用して組織を対象とする高度な脅威、侵害されたID、および悪意のあるインサイダーによるアクションの識別、検出、調査を行う。

●特権アクセスのコントロールと、Azure ADで利用できる機能

　ID管理（IM）のコントロールと同じように、特権アクセス（PA）のコントロールも見てみよう。

ASBにおける特権アクセス（PA）のコントロール

特権ID管理（PIM）：
　特権ID管理（PIM）は、PA-1、PA-3、PA-5、PA-7などに関わる重要な対応手段となる。

　Azure AD 特権ID管理を使うと、Azure リソースおよびAzure ADへのジャストインタイム（JIT）特権アクセスを有効にすることができる。これは、ユーザーが必要な場合にのみ、特権タスクを実行するための一時的なアクセス許可を付与できるものだ。

特権ロール管理の全体フロー

　もちろん監査の観点も忘れてはならない。Azure AD 特権ID管理は、Azure AD組織に疑わしいアクティビティや安全でないアクティビティがある場合に、セキュリティアラートを生成することもできる。

　さらに、Azure ADアクセスレビューを使用すれば、グループメンバーシップ、エンタープライズアプリケーションへのアクセス、および役割の割り当てを確認できる。Azure ADレポートは、古いアカウントの検出に役立つログを提供できる。

　定期的なレビューをプロセス化し、それを容易にするアクセスレビューレポートワークフローの作成も行うことができる。さらに、過剰な数の管理者アカウントが作成されたときにアラートを出し、古いアカウントや不適切に構成された管理者アカウントを識別するように構成することができる。

特権アクセスワークステーション：
　PA-6に限らず、セキュリティ保護された安全で隔離されたワークステーションは、管理者、開発者、重要なサービスオペレーターといった機密性の高い役割のユーザーには重要になる。それらの役割の管理タスクでは、高度にセキュリティ保護されたユーザーワークステーションやAzure Bastionを使用する。Azure Bastionは、Azure VMなどにAzure Portalからアクセスすることができる“踏み台”のようなPaaS機能だ。

　またAzure AD、Microsoft Defender for Identity、またはMicrosoft Intuneを使用して、管理タスク用の安全で管理されたユーザーワークステーションを展開することもできる。保護されたワークステーションを一元管理して、強力な認証、ソフトウェアとハードウェアのベースライン、制限された論理アクセスとネットワークアクセスなどの保護された構成も可能だ。

Customer Lockbox：
　PA-8のようなトラブル時のサポートでは、まれにではあるがMicrosoftのエンジニアが顧客データにアクセスしなければならないケースもある。そうした状況では、Microsoft Azure用 Customer Lockboxに顧客データへのアクセス要求を承認または拒否するインターフェイスが用意される。顧客の承認を得てMicrosoft側からのアクセスが行われ、その履歴や監査ログを残すことができる。

★まとめ：Well-Architected FrameworkとAzure Security Benchmark

・戦略に従ったうえで、実装におけるベストプラクティスはW-AFを参考とする。そしてW-AFのベストプラクティスを取り込んだASBの内容は、実利用に向いている。
・ASBでは、概念だけでなく実践的な各サービス利用についてもガイドされている。