前回「Azure の基礎　その１１　セキュリティ後編」の続きです。

今回はラーニングパス「Azure の基礎 第 5 部:ID、ガバナンス、プライバシー、およびコンプライアンス機能に関する説明」の概要を書いていきたいと思います。

Azure AD と Active Directory

この2つはきちんと使い分けて理解したほうが良さそうです。Azure AD = Azure Active Directory で、ただの Active Directory はオンプレの Active Directory という使い分けがされています。

オンプレミス環境の場合、Windows Server で実行される Active Directory は、自分の組織によって管理される ID およびアクセスの管理サービスを提供します。 Azure AD は、Microsoft のクラウドベースの ID およびアクセスの管理サービスです。 Azure AD では、ユーザーが ID アカウントを制御しますが、サービスがグローバルに利用可能であることを Microsoft が保証します。 Active Directory を使用したことがある場合は、Azure AD にすぐに慣れることができるでしょう。

オンプレミスで Active Directory を使用して ID をセキュリティ保護する場合、Microsoft はサインインの試行を監視しません。 Active Directory を Azure AD と接続すると、Microsoft が追加費用なしで疑わしいサインインの試行を検出することによってお客様の環境が保護されます。 たとえば、Azure AD は、予期しない場所または不明なデバイスからのサインインの試行を検出できます。

Azure AD の提供機能

機能	詳細
認証	アプリケーションとリソースにアクセスするための ID の確認、セルフサービスによるパスワードのリセット、多要素認証、禁止されているパスワードのカスタムリスト、スマートロックアウトサービスなど
シングルサインオン（SSO）	ユーザーは 1 つのユーザー名と 1 つのパスワードを記憶するだけで複数のアプリケーションにアクセスできるようになります。ユーザーがロールを変更したか、退職したときに、アクセス変更がその ID に関連付けられ、アカウントを変更したり、無効にしたりするために必要な労力が大幅に減少します。
デバイス管理	個々のユーザーのアカウントと共に、Azure AD はデバイスの登録をサポートしています。 登録により、Microsoft Intune などのツールを使用してデバイスを管理できるようになります。 また、デバイスベースの条件付きアクセス ポリシーで、要求元のユーザーアカウントに関係なく、既知のデバイスからのアクセスのみに制限することもできます。

Azure のガバナンス戦略

クラウドの運用において課題となるのが、その利便性とワークフロー制御によるガバナンスのバランスです。

厳格なワークフローにより、リソースのプロビジョニング、アクセス制限を行うと、作業の都度、申請や承認が必要となり、時間だけが掛かってしまいます。

このようなガバナンスの課題に対して、Azure ではどのような解決方法があるでしょうか。

Azure 向けクラウド導入フレームワーク

クラウド導入フレームワークという、Azure を始めるにあたっての計画を事前に立てられるフレームワークがあります。

このフレームワークに沿って Azure 上でのシステム構築を行えば "バッチリ!" なはずです！

サブスクリプションレベルの Azure ガバナンス戦略

サブスクリプションレベルでは、課金、アクセス制御、サブスクリプションの制限を考慮しておかなければいけません。

また、それらをまとめる管理グループの制限も考慮した上で、システムの全体像を考えておかななければいけません。

考慮事項	詳細
課金	サブスクリプション単位で課金されます。組織単位で予算を割り当てる場合は、組織単位にサブスクリプションを割り当てる必要があります。
アクセス制御	すべてのサブスクリプションは、Azure Active Directory テナントに関連付けられています。 各テナントを使用することで、管理者は、Azure のロールベースのアクセス制御を使用して定義されたロールを介してアクセスをきめ細かく設定できます。 サブスクリプション アーキテクチャを設計するときは、デプロイ境界の要因を検討します。 たとえば、開発用と運用環境用に個別のサブスクリプションが必要ですか。 個別のサブスクリプションを使用すると、それぞれに対するアクセスを個別に制御し、リソースを互いに分離できます。
管理グループ、サブスクリプションのクオータ	サブスクリプション当たりのリソースグループ数は最大で980です。サブスクリプションへ直接デプロイ可能な Azure Policy や Azure RBAC は最大で800です。 利用者数やリソース数が増えてきますと複数のサブスクリプションでの運用が必須となるでしょう。詳細は「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照ください。

RBAC（ロールベースのアクセス制御）

ロールとスコープについての関係性です。

いくつか例を挙げます。

• 管理グループのスコープでユーザーに Owner ロールを割り当てると、そのユーザーは、その管理グループ内にあるすべてのサブスクリプションのすべてのものを管理できます。
• Reader ロールをサブスクリプションのスコープでグループに割り当てると、そのグループのメンバーは、そのサブスクリプション内にあるすべてのリソース グループとリソースを表示できます。
• リソース グループのスコープでアプリケーションに Contributor ロールを割り当てると、そのリソースグループ内のリソースを管理できますが、サブスクリプション内の他のリソースグループは管理できません。

リソースのロック

ロックは、サブスクリプション、リソース グループ、または個々のリソースに対して適用できます。 ロック レベルは CanNotDelete または ReadOnly に設定できます。

---	---
CanNotDelete	承認されたユーザーはリソースの読み取りと変更を行うことができますが、先にロックを削除しないとリソースを削除できないことを意味します。
ReadOnly	承認されたユーザーはリソースを読み取ることはできますが、リソースの削除または変更はできないことを意味します。 このロックの適用は、すべての承認されたユーザーを、Azure RBAC の Reader ロールによって付与されるアクセス許可に制限するのと似ています。

タグ管理

タグによるリソースの管理は AWS でも重要ですね。

システム識別子や、環境識別子、コスト識別子、セキュリティレベル、ビジネスインパクト、などといった情報をタグとして各リソースに付与しておくことで、用途に応じたグループ分けが可能です。

Azure Policy

Azure Policy は、特定のリージョンでのみリソースが作成できる、といった制限や、リソースグループ内のリソースにはタグを継承させる、といった設定が可能です。

それ以外にもたくさんのポリシー定義が可能です。組み込みのポリシーの一覧はこちらです。

ポリシーを割り当てて、リソースが準拠しているかどうか、評価ポイントとして確認することもできますし、ポリシーに準拠しないリソースは作成できないといった制限も可能です。

イニシアティブとは、関連するポリシーを 1 つのセットにグループ化したものです。

ポリシー・イニシアティブを割り当てる方法

ポリシーの割り当てと同様に、イニシアティブの割り当ては、管理グループ、サブスクリプション、またはリソースグループに対して可能です。

ポリシーが 1 つしかない場合でも、イニシアティブを使用すると時間の経過と共にポリシーの数を増やすことができます。関連付けられたイニシアティブは割り当てられたままなので、リソースのポリシー割り当てを変更する必要なしに、ポリシーを簡単に追加したり削除したりできます。

Azure Blueprints

クラウド環境が 1 つのサブスクリプションに収まらないほど大きくなり始めたらどうなるでしょう。

例えば、企業として、ISO 27001 への対応が求められたとします。ISO 27001 は、国際標準化機構によって公開されている、IT システムのセキュリティに適用される標準です。

一つ一つのリソースに対して、規則に遵守しているかどうかをチェックするのは大変です。

そこで、Azure Blueprints には、ISO 27001 に関連する組み込みのブループリント定義がありますので、これを利用します。

設定方法は簡単です。

1. 管理グループを定義
2. ブループリント定義を ISO 27001: 共有サービスブループリントテンプレートを基にして作成
3. 作成したブループリントを PROD-MG 管理グループに割り当て

このように会社全体でのコンプライアンスを Azure Blueprints で定義することで、手間なくコンプライアンス遵守が可能になります。

最後に

Azure AD とリソースグループ、サブスクリプション、管理グループ、Azure Policy に関する比重が重かったように感じます。

Azure の基礎、というラーニングパスも残すところ後１部となりました。

以上です。

ActiveDirectory