「Cloud IdentityとAzure ADの基礎を比較」というタイトルで登壇しました Vol2 #devio2023
資料
タイトルを選んだ経緯
前職で少しだけMicrosoft Sentinelを触っていた過去があり、クラメソではGoogle Cloudを担当しています。
さらに、資格についてもAzure、Google Cloudともに9個ほど取得していて、その中でも私が1番興味のあるID管理周りの情報を登壇を介して、皆様にお伝えしたかったからです。
注意
このセッションブログは前半Vol1（Google Cloudメイン）と後半Vol2（Azureメイン）に分かれて記事にしています。
クラウドを触るときの IdP の役割までは前半のVol1の投稿と同じです。（それ以降に今回の新しい内容が含まれます）
はじめに
内容としては、機能の優劣を比較するものではありません。
Microsoft Azure、Google Cloudを使用する上で必要なID管理基盤の概念と仕組みの違いを解説します。
この辺りの知識は、資格試験でも問われるものになりますので、AzureのSC-200やGoogle CloudのProfessional Cloud Architectでも役に立つ情報かと思います。
【補足】
Azure Active Directoryの名称が、Microsoft Entra IDへと変更されましたが、今回はAzure ADとして話を進めていきます。（ちなみに機能に大きな変更はないようです）
クラウドを使用するには何が必要?
Google Cloud （旧GCP）
ここで必要なリソースは、「Google アカウント + プロジェクト + （請求先アカウント）」になります。
Google アカウントとは？
[email protected]のような単体のユーザーを指します。
こちらは、企業所有のドメインで作成しているアカウントでも、無料のGmailアカウントでも、どちらでも問題ありません。
プロジェクトとは？
上で説明したGoogle アカウントを使用して、プロジェクトを作成します。
こちらは、リソース（BQやGCS,GCEなど）を作成する時に必ず必要となる一種の課金単位のようなものです。
請求先アカウントとは？
こちらはなくてもGoogle Cloudの登録はできるのですが、作成しないとほぼGoogle Cloud内のリソースは触れません。
クレカを登録して、使用できるリソースを増やすために使用するアカウントです。（請求をまとめたりもできます）
Microsoft Azure
ここで必要なリソースは、「Azure AD + サブスクリプション + （リソースグループ）」になります。
※ Microsoftアカウントは一旦無視します
※ Azureにも請求プロフィール、請求アカウントという課金アカウントも存在します。
Azure AD
MicrosoftのIdPサービスであり、AzureADユーザーを作成し、そこで初めてAzureを操作することができます。（Azure AD と Microsoft Azureは別物です）
サブスクリプション
必ずAzure ADに紐づく形で登録をします。（ぶら下がる形で使用する）
【関係性を画像にまとめます】
リソースグループ
AzureではVMやVPCを作成する時に、必ずリソースグループが必要となります。Azure内のリソースを論理的にグループ化する方法で、リソースを管理し、リソースのアクセス制御などの役割を果たします。
Azure AD と Azureサブスクリプションの課金は別
ここでは少し毛色の違う説明となりますが、Azure ADはIdP単体としての機能を提供し、課金は別です。
また、Google Cloudの請求先アカウントと同じように請求の情報を登録する役割を持つ、請求プロフィールと請求アカウントというものが存在します。
クラウドを触るときの IdP の役割
Google Cloud Cloud Identity
Google Cloudを使用する際にはオプションとして提供されています。（＝必須ではない）
また、Free or Premium の選択肢が用意されています。
Azure Active Directory
Azureを使用する際には必須のリソースとして提供されています。 Freeプラン P1プラン P2プラン Microsoft Entra ID Governanceの選択肢が用意されています。
Azure Active Directory（Azure AD）
Azureを開始する時には、必ずAzure ADが必要になります。
Azure AD テナントと呼ばれることもあり、クラウドを触る時にIDPが必要な点もGoogle Cloudと大きく異なる点です。
さらに、Azure ADの中にユーザーを作成していくことが前提なので、Google Cloudのように個々のアカウント（Googleアカウント）を使用しません。（Microsoftアカウントは例外）
Azureを使用する際には、Azure サブスクリプションという課金単位の中にリソースグループとリソースを作成していきます。（Google Cloudでいうプロジェクト）
そして、このサブスクリプションは1つのAzure ADに必ず所属することになります。
Azure ADの役割
ユーザーとグループの管理
基本的にはIdPなので、ユーザーやグループ、アプリケーションの権限周りを管理します。 また、一見勘違いしやすいですが、Azure サブスクションとAzure ADの権限管理は別物になります。
権限の例
- グローバル管理者 → Azure AD（テナントへの権限）
- オーナーロール → サブスクリプション（RBAC）
IDとアクセス管理
権限管理に付随することでもありますが、ユーザーの認証/認可、SSO、アカウント保護（二段階認証や暗号化など）も多様に用意されています。
Azure AD 機能の例
- Azure B2B、Azure B2C
- 監査、レポート機能
- 特権ID管理（Privileged Identity Management：PIM）
- Identity Protection機能
Azure ADのテナントと組織
AzureとAzure ADの関係性の話がでたので、どのようにこの二つを関連させるのが効果的なのか？について少しまとめました。
- 1組織につき、1つのAzure ADテナントを使用（推奨）
- 他のテナントのリソースを触りたい
- Guest Inviter 機能が存在する
- セキュリティのため（野ばなしのアカウントの防止などのために）
基本的には、Azure ADの世界にユーザー（室井というユーザー）は1人存在すれば良いように設計されており、もし企業間でAzureサブスクリプション内のリソースを触らせて、協業したい場合には、Azure AD BtoBを使用すると、達成できます。
Azure ADとサブスクリプションの権限管理
ここでは、それぞれの権限についてまとめます。
Azure ADの権限（Azure ADディレクトリロール）
- Global Administrator
- Microsoft365の権限も合わせ持つ、全権限を保持する管理者
- User Account Administrator
- ユーザーに権限を付与する
- Guest Inviter
- 他のAzure ADユーザーを招待する
- Privileged Role Administrator
- 時限性/期限付きの権限割り当てを行う
Azure リソースへのアクセス権限（RBAC）
- Owner
- サブスクリプション全ての権限を持つ
- User Access Administrator
- ユーザーへの権限の割り当てが可能
- Contributor
- 権限の割り当て以外が可能、編集者としてほぼ全てのリソースを操作可能
- Reader
- 読み取りアクセスが可能
権限について
今回は割愛していますが、RBACロールの割り当てについては、適応させるスコープによって変わってきます。（サブスクリプション単位、リソースグループ単位、リソース単位...etc）
また、Azure ADのGlobal Adminについては、緊急用としてそのテナント配下のサブスクリプションのOwnerロールを取得するという特別な機能も存在します。
それぞれで似ている権限はありますが、大切な共通するポリシーとしてはGlobal AdministratorやOwnerのロールは安易にユーザーへ割り当てない方がいい、という考え方です。
もし、企業のAzure環境にこの2つのスーパーユーザーが多数存在した場合にユーザーアカウントがクラック（漏洩）されてしまうと、ほぼ会社のインフラを乗っ取られたと同じになってしまいます。
また、このような特権IDやアカウント自体を保護する対策として、Azure ADプレミアムでは、PIMなどのセキュリティ機能が存在しています。
Azure ADのセキュリティ機能
Privileged Identity Management（PIM）
基本的には特権周りの管理を行うために使用するのがこのPIMになります。
PIMの役割と機能をまとめました。
- 権限を付与するためのロール
- オンデマンドで割り当てが可能
- 期限付き：60minだけ 付与/剥奪
- Azure ADとAzureリソースに対するJust-In-Timeの特権アクセスの提供
- アクセスレビュー
- 特定のロール（権限）の棚卸しを行う
Identity Protection
この機能を使用すれば、異常な行動やリスキーなサインインをリアルタイムで検出することができるようになります。
Identity Protectionの役割と機能をまとめました。
リスクベースの条件付きアクセスポリシー
- サインイン時のリスクを評価
- ユーザーがサインインを試みる際のリスクレベルを評価
（例）不審なIPからの接続や異常なログイン試行といったパターンが検出された場合、リスクが高まると判断し、評価されたリスクレベルに基づいて、条件付きアクセスポリシー（ユーザーに対する追加的な認証要求やブロック）が適用される
- ユーザーアカウントの危険度を評価
- ユーザーアカウントが危険にさらされていることを示すシグナルを評価
- ブラックマーケットを見張る
（例）不正な取引所でユーザーの資格情報が売買されていることが確認された場合、そのユーザーのリスクレベルが上昇し、そうしたシグナルが検出された場合にも、特定のアクション（例えばパスワードのリセット要求など）がトリガーされる
Azure AD BtoB BtoC
Azure ADで企業間の協業やサードパティのコンシューマ向けのIdPと認証を連携させることができるのも特徴です。
Azure AD BtoB
- 企業間での協業を支援する機能
- 自社のAzure環境のインフラ構築のために、他の企業のAzure ADテナントに所属するAzure ADユーザーを招待し協業する
Azure AD BtoC
- コンシューマー向けのID連携を提供する
- 自社開発の「一般ユーザー向けのショッピングアプリケーション」を使用させる際に、Azure ADとFacebookやTwitterを連携させて、ユーザー認証はFacebookやTwitterに委任し、Azure ADで認可する
まとめ
今回はAzure ADのみ
実際のセッション内容をなるべくブログにまとめたいので、Vol1とVol2に分けました。
前回はAzure AD関連のセッション内容をブログにしておりますので、前編後編を読むと比較がしやすいかと思います。（基本的にIdPの役割として共通するのはセキュリティ周りです）
前回の記事
「Cloud IdentityとAzure ADの基礎を比較」というタイトルで登壇しました Vol1 #devio2023
最後に
初心者女性のトレーニングは自重でも十分 （男性も）
「筋トレで美しくなりたい」
そんな声が巷から聞こえるので、今回は自宅でも十分に効果のあるトレーニングはできますよって話をします。
何故なら、筋トレとはマシンやダンベルを使うことが目的ではないからです。
筋トレの目的はなんですか？？
そう、それは「筋繊維を破壊して、修復させる」プロセスこそが筋トレの目的だと私は思っています。
とは言っても、筋肉が大きくなるメカニズムを知っていないとピンとこないかも知れません。
筋肉は、トレーニングによりダメージを受け、そして数十時間で回復します。
その回復の時に以前の状態よりも強く（または大きく）なることにより、筋トレの効果を得ることができます。
少し遠回りになりましたが、要は家でできる筋トレでも筋肉に適切にダメージを与えればジムと同じ効果を発揮します。
ジムに行かなきゃしっかりとした筋トレはできないとお思いの方が多い印象を受けるのですが、それは違います。
しっかりとした筋トレはジムが作るのではなく、自分で作るのです。
ものは考えよう、家トレは筋トレの宝庫ってことでまとめましょう。
