本シリーズの記事について
Azure OpenAI Service が大きな話題を呼ぶ中で、今まで Azure サブスクリプションを持っていないかったユーザーの Microsoft Azure の新規利用が増えています。その際、EA 契約 (EA/ESA/SCE契約) や CSP 契約ではなく、オンラインでサインアップして Azure サブスクリプション作成されるケースが散見されます。この方式は気軽に Azure を触ってみるには手っ取り早く便利です。
Microsoft Azure を組織やビジネスでセキュリティやガバナンスを意識して利用するには、仕組みを理解しアーキテクチャ設計を行う必要があります。特に Microsoft Entra ID (Azure AD) をベースにした認証・アクセス管理はその中でも重要な要素です。
また、ウェブサイトで Azure サブスクリプションを新規作成した場合は、Azure Plan と呼ばれる従量課金プログラムで利用することになりますが、その請求を管理する課金アカウント (マイクロソフト顧客契約 (MCA) の請求先アカウント) をどう管理するか、もとても大切です。
一方で、2024年1月時点で、まだまだこのあたりに苦戦しながら試行錯誤で Azure を使い始めたユーザーも多いかと思います。
上記記事より引用
🛫AOAIが出てから初めてAzureを触ってみた方急増
Azure OpenAI Service で初めてAzure触ります勢に向けて、マルチクラウドでの連携や、初めてAzure触ってみての感想、意外とここがいい、つらみなどの知見が盛りだくさんの資料でした。よく言われたフレーズ3選としては、① サブスクリプションってムズい ② Azureのアカウント開設どうするの ③ Entra ID (Azure AD)の認証、アカウント周りがむずい、でした。
ですので、本シリーズではなるべく平易に Entra ID と課金アカウント、サブスクリプションの仕組みやアーキテクチャ設計をご紹介したいと思います。(Azure の正しい始め方と銘打っていますが、あくまで個人としての私見になる点ご了承ください。)
なお、MCA 課金アカウントの Azure Plan サブスクリプション以外の場合 (MOSP, EA契約, CSP契約など) は、本記事の内容とは一部異なる点がありますのでご注意ください。
Azure の正しい始め方 ①-④
まず、本記事では、全体のアーキテクチャと主要な要素の基本を見ていきます。
第２弾以降の記事は以下にあり、それぞれ Entra ID、課金アカウント、サブスクリプションを深堀していきます。
サブスクリプション (Azure Plan)、Microsoft Entra ID (Azure AD)、課金アカウント (マイクロソフト顧客契約 (MCA)) の基本情報
まず最初に、従量課金の契約と課金、Microsoft Entra ID も含めた全体像を見ていきます。
1. 課金アカウント (請求先アカウント) とマイクロソフト顧客契約 (MCA)
2024年1月時点で、Azure のウェブサイト で従量課金のサインアップを行うと、MCA (マイクロソフト顧客契約) に同意することが求められ、この MCA をベースにした課金アカウント (請求先アカウント) というサブスクリプションの利用料金の支払い用のアカウントが払い出されます。
課金アカウントは、Azure Portal のコストの管理と請求の画面から確認ができます。
そもそもの MCA (マイクロソフト顧客契約) がどういった契約であるか、については下記の公式ウェブサイトをご覧ください。
サインアップ時には、この課金アカウントと合わせて最初のサブスクリプションが作成されます。もし複数のサブスクリプションが必要な場合は、この課金アカウントのページから新規のサブスクリプションの払い出しができます。
また、この種別の課金アカウントに紐づく従量課金の Azure サブスクリプションは、Azure Plan と呼ばれる為替変動型の従量課金のプログラムとして費用が計算されます。次にこのサブスクリプションについて見ていきます。
2. Azure サブスクリプションと Azure Plan
Azure におけるサブスクリプションとは、課金・管理・スケールの単位です。
Azure のリソースはすべてそれぞれひとつのサブスクリプションに紐づいて作成され、そのサブスクリプションごとに請求がされます。サブスクリプションをどの単位で作成すべきか、サブスクリプション内のリソース管理をどうするべきか、複数サブスクリプションをまとめて管理する手法があるか、については本シリーズの第四弾にてご紹介します。
課金については、契約種別により課金の計算方式 (為替等) が若干異なりますが、今回は Azure Plan という課金体系のものを見ていきます。
Azure Plan のサブスクリプションは各月の為替レートが前月末に決定され、円ベースだと毎月変動する課金体系になっています。このあたりの価格の決定の仕組みについては下記 FAQ に明記されています。
自身のサブスクリプションが Azure Plan のものかどうかは、Azure Portal のサブスクリプションのページから確認ができます。
(補足) MCA ではない従量課金の契約形態 - MOSP (マイクロソフトオンラインサービスプログラム) とは？
以前に Azure にサインアップして、課金アカウントとサブスクリプションを作成している場合、課金アカウント (請求先アカウント) の種類が、MOSP (マイクロソフトオンラインサービスプログラム) になっている可能性があります。この場合は、課金アカウントの考え方や利用料金の請求の為替の考え方が MCA (マイクロソフト顧客契約) と異なります。 そのため、本記事の解説内容とは異なる点が複数ございますのでご注意ください。
また、MOSP と MCA の請求の違いについては、下記の記事がわかりやすくご説明されていらっしゃいました。
また、マイクロソフト社のサポートチームからそれぞれの確認方法について、一覧で解説する記事が出ています。
MOSP のサブスクリプションの場合、Azure Portal のサブスクリプションページではプロパティで下記のように見えるはずです。
また、MOSP の課金アカウントはこのようになっています。
(補足) MCA 課金アカウントの従量課金サブスクリプションが最適な Azure の利用形態か？
そもそも論ですが、Azure を利用するにあたり、本記事でご紹介する MCA 課金アカウントの従量課金 (Azure Plan) サブスクリプションが必ずしもすべてのケースで最適ではありません。組織や法人による大規模な Azure 利用の場合は、EA 契約 (EA/ESA/SCE契約) や CSP 契約のほうが適している場合も多いです。それぞれの契約形態の比較については下記もご参照ください。 (マイクロソフト社の Azure 利用ガイド2024年1月版より抜粋)
CSP 契約の場合は CSP パートナー、EA 契約の場合はマイクロソフト社の LSP (Licensing Solution Partner) から購入することになります。
(補足) Azure のサブスクリプションの契約種別の変更について
もし使い始めた後に、サブスクリプションの契約種別を変えたくなった場合、とりうる手法は主に２つあります。ただし、いずれも制限が強く、望んだような変更ができないケースも多いです。基本的には、使い始める前にどの契約種別が利用に適しているかを検討したうえで、Azure サブスクリプションを使用することがおすすめです。
① サブスクリプションの契約種別の移管
契約種別によっては、サブスクリプションを別の契約に紐づけることができます。詳細については下記をご覧ください。また実際の移管作業前にはサービスリクエストを作成し、マイクロソフト社のサポートに問い合わせることを個人的にはおすすめしています。
② サブスクリプション内のリソースの、別サブスクリプションへの移動
もしサブスクリプションごとの移管ができない場合は、リソースごとに別契約内の別サブスクリプションに移動させることが選択肢になってきます。ただし、こちらもリソースごとにサブスクリプション移動ができる・できないがありますので、事前に確認いただいたうえでご実施ください。
3. Microsoft Entra ID
課金アカウントとサブスクリプションに加えて、なくてはならないのが Microsoft Entra ID というマイクロソフトクラウドの中で ID 管理をつかさどるサービスになります。
特に、Azure サブスクリプションから見た時は、Microsoft Entra ID はユーザーやグループのディレクトリとユーザーの認証機能を提供しています。次稿では、この Microsoft Entra ID をどう構成すべきかについて詳述します。
本記事では、全体的なアーキテクチャとして課金アカウントやサブスクリプションから見て、Microsoft Entra ID とどう連携すべきかをとらえていきます。
アーキテクチャ設計の全体像
Azure の管理において、課金アカウント、サブスクリプション、Microsoft Entra ID は三位一体となって機能します。課金アカウントは ひとつの Microsoft Entra ID をプライマリテナントとして関連付き、サブスクリプションは同じくひとつの Microsoft Entra ID を信頼する形でユーザーディレクトリとして利用します。
シンプルな理想形のアーキテクチャ
MCA の課金アカウント (請求先アカウント) を新規で作成し、サブスクリプション (Azure Plan) を払い出す場合、シンプルかつ多くの場合で理想的な構成は下記になります。
シンプルイズベストは、Azure の基盤のアーキテクチャに対しても適した表現といえます。組織によっては、Microsoft Entra ID が乱立し、部署や部門ごとに Azure の契約を持ち、組織内のサブスクリプションの数が把握できなくなってしまっているというケースも出てきています。ですが、こういった状態だとセキュリティ・ガバナンスに大きな問題を抱え、リソースやコストの最適化も困難になってしまいます。
対して上のアーキテクチャでは、Microsoft Entra ID のディレクトリがひとつであることが重要なポイントとして挙げられます。もし Microsoft 365 をすでにお使いの場合は、同じディレクトリで Azure を管理することが第一の選択肢になります。またマイクロソフトのクラウドサービスを使ったことがなく、Azure が初めてになる場合は、組織用のディレクトリを用意し、自社・自組織のメインのディレクトリとして整備したうえで Azure を使い始めるのがベストです。ディレクトリとしての構成については次記事にてご紹介します。
そして、課金アカウントのプライマリディレクトリをその Microsoft Entra ID とし、またサブスクリプションの信頼先のディレクトリも同ディレクトリにします。 課金アカウントのプライマリディレクトリもサブスクリプションの信頼先ディレクトリも複数のディレクトリを同時に指定することは仕様上できません。課金アカウントのプライマリディレクトリとサブスクリプションの信頼先ディレクトリを別テナントにすることは可能ではありますが、構成が複雑になり管理も難しくなるため基本的にはおすすめしません。
マイクロソフトクラウドにおいて、ディレクトリが分かれるというのは基本的に組織が分かれることを意味します。そのため、別ディレクトリ内のサブスクリプションや課金アカウントは、そのディレクトリの内部に入らない限り基本的には見れません。もし社内で野良ディレクトリが乱立し、その中で Azure 課金アカウントやサブスクリプションが作られてしまうと、情報システム部門や CCOE がそれをとらまえることが困難になり、シャドーITの温床になってしまいます。
(補足) Microsoft 365 と Azure を同ディレクトリで利用する必要性について
特に以下のサービスを Azure で利用する可能性がある場合、Microsoft 365 と Azure を同じ Microsoft Entra ID に紐づけて利用することがおすすめです。
- Azure Virtual Desktop
- Microsoft Defender for Cloud
- Microsoft Sentinel
- Microsoft Purview
アーキテクチャ設計で確認しておきたいチェックリスト
次記事以降で Microsoft Entra ID や MCA の課金アカウントについて詳細を見ていきますが、その道標となるチェックリストをこの段階では見ておきたいと思います。サブスクリプション・課金アカウント・Microsoft Entra ID のアーキテクチャ設計において、これらの項目は常に頭に入れておきたいリストになります。
- マイクロソフト顧客契約 (MCA) の課金アカウントで、Azure Plan のサブスクリプションを作成するのが、今回の Azure 利用に適切な契約形態か？
- Azure を利用するにあたり、課金アカウントやサブスクリプションを紐づける組織の必要最小数の (理想的にはひとつの) Entra ID のディレクトリを用意できているか？
- セキュリティ要件に合わせて、必要な Entra ID のライセンスを明確にし、必要ユーザー分購入しているか？
- Azure をセキュアに利用するのに十分な Entra ID の設定 (MFA、 条件付きアクセス、ログ送信設定など) を完了しているか？
- Azure にサインアップするための組織アカウント (利用する Entra ID 上のユーザーアカウント) を用意しているか？課金アカウントのプライマリディレクトリがどこになるか把握しているか？
- 課金アカウントの管理者を明確にし、その課金アカウントの IAM (アクセス設定) を構成をしているか？
- 作成するサブスクリプションの信頼先ディレクトリが明確に決まっているか？そのディレクトリのユーザーに対して、サブスクリプションの IAM (アクセス設定) を正しく構成できているか？
- サブスクリプションをどういった単位で切るか決定しているか？複数にわたる場合、管理グループの階層構造を用意しているか？
次に、サインアップ時の最初の注意点として、マイクロソフトアカウントと組織アカウントの違いを見ていきます。
Azure への最初のサインアップ時の注意点 - 組織アカウント利用のススメ
基本的に、Azure にサインアップする前に、組織として利用する Microsoft Entra ID のディレクトリを用意することをおすすめしています。特に Azure のサインアップについて、マイクロソフトアカウントというコンシューマ向けアカウントを使うこともできるのですが、こちらは組織としてのビジネス利用で Azure を使用するのには向いていません。
Entra ID のディレクトリを用意したうえで、そのディレクトリ上のユーザー (組織アカウント) でサインアップをすることで、Entra ID と課金アカウント、サブスクリプションがきれいに整理された状態で生成されます。
(補足) マイクロソフトアカウントと組織アカウントとは？
マイクロソフトアカウントとは各個人がマイクロソフトのコンシューマ向け製品を使うために、個人のメールアドレスでサインアップして利用するアカウントです。サインインはマイクロソフトが管理するクレデンシャル情報を使って行われます。
一方、組織アカウントとは、Microsoft Entra ID 上のユーザーアカウントを指します。Entra ID は ID as a Service のため、認証はマイクロソフトのサービス上で行われますが、たとえば個々のユーザーのパスワードリセットや多要素認証の強制などは、Entra ID のディレクトリの管理者が行います。
両者の違いの詳細については、下記のサポート記事をご覧ください。特にひとつのメールアドレスがマイクロソフトアカウントでもありかつ組織アカウントでもある際、どちらとして動作しているかが重要になりますが、その見極め方なども詳述されています。
そして、まず Azure を組織・ビジネス利用する際は、なるべく組織アカウント (= Microsoft Entra ID 上のユーザーアカウント) で Azure をサインアップし、利用することが推奨です。
その理由についてこれから見ていきます。
マイクロソフトアカウントと組織アカウントの Azure サインアップの違い
そもそも、Azure サブスクリプションや課金アカウントの管理には、必ず Microsoft Entra ID のディレクトリが必要です。組織アカウントでサインアップする場合は、自身の所属するディレクトリ (=プライマリディレクトリ) に紐づいて課金アカウントが生成され、サインアップしたユーザーに課金アカウントの所有者権限が付与されます。また Azure サブスクリプションはユーザー自身の属するディレクトリを信頼するように作成されます。
一方、マイクロソフトアカウントを使ってしまうと、そのディレクトリが存在しないため、マイクロソフトが勝手に一つディレクトリを生成して、そのディレクトリ上のゲストユーザーとしてマイクロソフトアカウントを追加してしまいます。(より厳密には、マイクロソフトアカウントであるユーザーを <メールアドレス>#EXT#@<初期ドメイン名> という通常ゲストユーザーとして登録される UPN で、ユーザーの種類がメンバーになった状態でユーザー登録されます。ユーザーの種類がメンバーとなってはいるものの、パスワードはゲストユーザーと同じくマイクロソフトアカウント側で管理されます。)
その場合、デフォルトドメインが、***gmail.onmicrosoft.com や ***outlook.onmicrosoft.com といったメールアドレスの値を取ったドメイン名となった新規テナントを利用することになります。
マイクロソフトアカウントでサインアップした場合の様子を図で表すと、下記のような感じになります。
マイクロソフトアカウントでサインアップした場合のテナントの例
このディレクトリは最初、このマイクロソフトアカウントのユーザーのみが管理者状態であり、またゲストユーザーとして別ディレクトリ上のユーザーやマイクロソフトアカウントを追加はできるものの、組織で利用するには適していません。
特に防ぎたいのが、社内の個々人が自分のプライベートのマイクロソフトアカウントを使って Azure にサインアップし、それをそのまま組織・ビジネス用途で利用し続けるケースです。ディレクトリが異なる場合、サブスクリプションを発見することもポリシーをかけることも不可能になってしまいます。こういった事態を防ぐためにもあらかじめ組織で利用する Microsoft Entra ID をひとつ用意し、そのディレクトリを利用して Azure を管理するように決めておくのが理想的です。
組織アカウントでサインアップした場合の初期構成
組織アカウントでサインアップした場合、課金アカウントのプライマリディレクトリが、その組織アカウントが属する Microsoft Entra ID のテナントになります。また同時に作成される最初の Azure サブスクリプションもそのディレクトリを信頼するように生成されます。これにより、先の理想的なアーキテクチャで示した絵の通りの構成が自然とできあがります。
つまり、Azure を使い始める前に Microsoft Entra ID を準備し、その組織アカウントを使って意図的にサインアップを行うことで、想定するアーキテクチャで構成することができるようになっているというわけです。
初期構成の場合、自分がログインしているテナント (下記スクリーンショットの赤枠部分で確認可能) 内で課金アカウントが見れるようであれば、そのテナントが課金アカウントのプライマリテナントということになります。第三弾で詳述しますが、この課金アカウントに、その Entra ID のユーザーに対してアクセス権限を付与できます。
また、サブスクリプションのページからは、サブスクリプションが信頼しているディレクトリを確認可能です。こちらもこのディレクトリのユーザーに対してアクセス権限を振っていきます。
そういった意味でも、 Azure を使用開始にするにあたり、まず Entra ID から考えることが組織による利用・ビジネスのための利用においてはおすすめです。本シリーズでも、Azure の正しい始め方のネクストステップとして、第二弾では Microsoft Entra ID の準備をどう行っていくかについて見ていきます。
最後に
本記事では、オンラインで Azure にサインアップした際の、正しいアーキテクチャ構成を取るための第一歩として、課金アカウントやサブスクリプション、Microsoft Entra ID の基本的な考え方をご紹介しました。次回以降、Microsoft Entra ID、課金アカウント、サブスクリプションについて、それぞれどういった設定や構成が必要かを見ていきます。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。