見出し画像

最低限知っておきたいサブスクリプションと Azure AD テナント管理の基礎知識 - cafbc10 〜日本マイクロソフト

今日は日本マイクロソフトさんのYoutubeチャンネルから2023 年 6 月 7 - 8 日開催「 Cloud Adoption Framework Boot Camp 」のセッション動画「最低限知っておきたいサブスクリプションと Azure AD テナント管理の基礎知識」について紹介したいと思います。テナント管理の基本中の基本みたいなテーマですがとりあえず勉強してみます。

<動画>

なぜID管理、権限管理が重要か

パブリッククラウドを利用する上でID管理、権限管理の重要性

オンプレミスとパブリッククラウドの違い

オンプレミスとパブリッククラウドの違い

オンプレミス
・物理的、ネットワーク的な境界で防御
パブリッククラウド
・仮想マシンの中、DaaSの中などはネットワークの閉域化が可能
 ⇒データプレーン
・仮想マシンの立上・削除などサービス自体のデプロイ
 ⇒コントロールプレーン(Azure リソースマネージャー)
  閉域化できない:IDに基づいた認証と権限で境界

ゼロトラストネットワーク
・物理、ネットワーク、IDでの多層防御が推奨
 Azureは予めIDを使った多層防御を備わっている

IDによる防御

IDによる防御

Azureのコントローププレーン:AzureADを認証基盤
REST APIでAzureリソースマネージャにアクセスするには
・AzureADで認証しアクセストークンを取得
 部外者を認証でブロックすることが可能
・トークンには権限情報も含まれ、権限の範囲で閲覧・操作

AzureはID管理、権限管理でセキュリティ担保

AzureADロールとAzureRBAC、ユーザ(ID)管理

Azure ADロール
・AzureADそのものの管理
・Microsoft365、Dynamics365などAzure意外のサービスの権限
AzureRBAC
・Azureのコントロールプレーンの管理

AzureADロールによるIDの管理
・ユーザープリンシバル
 人間のID、ライセンスの付与、コントロールプレーンの付与
・サービスプリンシバル
 バッチスクリプトやアプリケーションのID
・マネージドID
 特殊なプリンシバルの組み合わせ、Azureのサービスのみ利用可能

AzureADのユーザー管理
・ユーザのIDはAzureADで作成が可能
・同じ業務、権限のユーザーはセキュリティグループにまとめる
・グループに対して権限を管理する

AzureADのユーザー管理

外部ユーザの管理
・AzureAD B2Bの機能でIDをAzureADに招待することが可能
・外部IDは普段使用しているIDを使ってSSOを行うことが可能


AzureADテナント、Azureサブスクリプション、リソースグループ、リソースの関係

スコーピングの考え方が重要⇒権限の範囲を区切る

AzureADテナント、Azureサブスクリプション、リソースグループ、リソースの関係

Azureのスコープは三階層
・サブスクリプション
・リソースグループ
・リソース

プリンシバルにはそれぞれのスコープに対して権限を付与
・上位のスコープに付与された権限は下位スコープに継承
・継承された権限は下位でオーバーライドすることはできない
・サブスクリプションひとつのAzureADテナントにのみ紐づく

AzureRBACのロール

Azureの具体的な権限
⇒複数の権限を束ねたロールの付与でコントロール

AzureRBACのロール

ロールの種類
・所有者:すべての管理
・共同所有者:アクセス権設定以外のすべての管理
・閲覧者:すべての参照
・ユーザーアクセス管理者:Azureリソースのアクセス権の管理
・各リソースのロール:各リソースの作業者、固有のロール

固有のロールの種類
サービス固有のロール(シェルやデータに対するロール)
・仮想マシン
・App Service
・SQL Database
・Strage

固有のロールの種類(例)

AzureRBACの推奨事項

実際の環境でどのように実装すべきか

スコーピング
本番環境のサブスクリプション/開発環境のサブスクリプション
分割しておくのがおすすめ
・利用できるサービスの上限値はサブスクリプションごとに設定

AzureRBACの推奨事項

・サブスクリプション内部ではサブシステムごとにリソースグループを分割
・リソースグループの粒度が広すぎるとセキュリティリスクは高まる
・リソースグループの粒度が細かすぎると運用が大変

権限付与
開発サブスクリプションの場合(甘め)
・サブスクリプションは所有者にシステム全体の責任者
・サブシステムのリソースグループごとには開発メンバー
⇒開発環境はスクラップビルドが多く裁量を大きく設定

本番サブスクリプションの場合(厳しめ)
・サブスクリプション所有者は開発と同じ
・リソースグループの所有者はサブシステムの責任者
・実作業者には共同作業者以下のロールを付与
 権限管理はできないようにし不要なユーザへの割当を防止
・IDをまとめたセキュリティグループに設定

他の推奨事項
・サブスクリプションの所有者は最大3人まで
・複数のサブスクリプション所有者を割り当てて、冗長性を確保
・所有者権限を持つ外部アカウントをサブスクリプションから削除
・サブスクリプションの所有者はMFAを有効にし侵害を防止
・チーム内で職務を分離(所有者権限を少数に)
・職務に必要なアクセス許可のみをユーザに付与
 サブスクリプション所有者はAzureADの変更が可能
 リソースグループ所有者はリソースグループを一括削除
 ストレージアカウント所有者はストレージアカウント削除

Azureの課金管理のロール

課金情報を管理するための権限

AZureの課金管理の構造(MCA:Microsoft顧客契約)

AZureの課金管理の構造(Microsoft顧客契約)

複数の契約形態が存在
⇒契約形態によって課金管理の考え方が異なる

新規にAzureにサインアップしたとき:MCAが適用
・請求先アカウントが登録される
 課金請求に関するトップレベルのオブジェクト
 サインアップしたときのアカウントに適用
・支払い方法を司る課金プロファイル
・サブスクリプションの請求書を司る請求書セクション
・サブスクリプションの課金制御化RBACでの制御も可能

Azureの課金管理ロール
課金特有のロール

Azureの課金管理ロール

ポータルの画面でもロールの割当の画面が異なる
・「コストの管理と請求」通常の設定とは異なっている事がわかる

コストの管理と請求

EA/SCE契約
・MCAと考え方異なる
・EAの場合はエンタープライズ管理者が与えられる
・契約を部門単にで分割することも可能
 部門管理者の配下でアカウント管理者を設定

EA/SCE契約

<資料はこちらから>



この記事が気に入ったらサポートをしてみませんか?