Cloud Solution Providerへの顧客テナント作成~権限付与時のバリエーションやそこにまつわる色々な話

久しぶりにブログをまともに書きます。リハビリです。

今回のネタはCloud Solution Providerへの顧客テナント作成時のバリエーション…ということで、完全にエンタープライズの、さらにCSP Directパートナーにかなり特化した話なので一般向けではないですが…。それでも、結構色々なしくみの勉強や頭の体操にはなりますので面白くはあると思います。

ただ、私も全部完全にわかっているわけではなく、また、使用の変化も結構ある領域なので、話半分に読んでいただければと思います。何かしら保証するものではありませんし、間違っていても責任とれません。すいません。

そして結論めいたものはなく「状況によってベストな解法は変わる」という意見です。すいません。

 

Cloud Solution Providerとは

Cloud Solution Provider、略してCSPは簡単に行言ってしまうと、マイクロソフトのクラウドソリューション(Azure, O365, Dynamics等)を顧客に対して提供するものです。

マイクロソフトのクラウドソリューションなんだからマイクロソフトから買うんじゃないの?という疑問が出ると思いますが、もちろん「顧客⇔マイクロソフト」という形で顧客とマイクロソフトとの間で直接販売する形態が基本です。これもクレジットカードだけあればすぐに購入して使いはじめられるダイレクト販売があったり、企業としてEnterprise Agreement契約の中で購入したり…など色々とやり方があります。

でも、マイクロソフトはパートナービジネスに積極的ですし、特に日本では企業としてどこかのSIerなりCIerなりにシステム構築を依頼する形態が多いです。これに対応するのがCSPです。「顧客⇔SIer/CIer⇔マイクロソフト」という形態となります。

顧客はCSPであるSIer/CIerから「サービス」を購入し、SIer/CIerは裏でマイクロソフトのクラウドサービスを活用してそのサービスを提供する、ということです。顧客からはマイクロソフトは全く見えない形となります。何かあった場合のサポートはSIer/CIerが対処します。顧客からマイクロソフトに直接のサポートを要求することはある意味では「できない」ということにもなります。

このあたりのビジネス形態の話はこのブログエントリの趣旨ではないので、このへんで…。

 

クラウド時代のID管理はAzure ADである

マイクロソフトテクノロジーにおいてオンプレミス時代のID管理の中心はActive Directoryでした。そして、クラウド時代のID管理はAzure Active Directoryです。

これはもちろんCSPにも当てはまります。

CSPプロバイダー(SIer/CIer)がCSP関連を管理する「パートナーポータル」には「顧客」という概念があるのですが、「顧客」それぞれはAzure Active Directoryのテナントに1対1で対応します。

たとえば「顧客」を新規作成する際には自動的にAzure Active Directoryテナントが作成されます。ドメイン名の指定が必須です。

あるいはすでに企業でO365を使用している等の状況がありAzure Active Directoryテナントを保持していればそれと紐付ける「再販業者関係の要求」というオペレーションもあります。

マイクロソフトのクラウドサービスは全てAzure Active Directoryに紐付いています。これをキーとして理解しなければいけませんし、CSPプロバイダーはActive Directory Directoryの設計を行わなければいけません。顧客としてもIDの管理は非常に重要ですので、CSPサービスを利用する時にそのIDをどのようにするのか(既存のAADを使うのか、新規にAADを作成して別管理とする(≒CSPベンダーに任せる))のかを選択しなくてはいけません。

 

Azure Active Directoryとマイクロソフトのクラウドサービスの関係

Azure Active Directoryとマイクロソフトのクラウドサービス群の関係はきちんと前提知識として理解しておく必要があります。

まず、企業としては唯一の本物の…とでもいうような1つのAzure Active Directoryを保持することになります。これは企業としてEA契約でマイクロソフトのクラウドサービスを購入した時に自動的に作成されます。例えばO365やDynamics 365の契約をするとその契約に紐付いて作成されます。ではAzureの契約をした時には?ここは歴史的経緯があり、タイミングによりまちまちの状況という認識です。ここは正確なことをわかっていないのであまり触れないことにしますが、Azureには複雑になってしまう理由となる機構があります。

 

Azureサブスクリプションの「規定のディレクトリ」

Azureサブスクリプション(≒Azure環境)には「規定のディレクトリ」という概念があり、さらにこれが「変更」できちゃうんです。歴史的にはそもそもこれができない時期もありましたし、マイクロソフトアカウントしか使えない時期もありまして…、それで色々と複雑な事になっています。私も過去に色々と苦労してましてブログエントリも結構書いてますね。

「Azureサブスクリプションへの権限追加は「既定のディレクトリ」に存在している組織アカウントしか対象にできない」という制約事項があり、それをまず抑えておく必要があります。

※実はAzureとしては上記の制約にはさらに例外がありまして…(サービス管理者がマイクロソフトアカウントなのか、組織アカウントなのかで挙動が変化します。)、それがさらに話をややこしくするのですが、CSPの文脈ではまずこの制約事項を抑えておけばOKです。

CSPにおいては顧客は全てAzure Active Direcotryに紐付いていますから、そこに紐付いて作成されるAzureサブスクリプションの規定のディレクトリもその顧客のAzure Active Directoryに紐づく事になります。

 

Azure以外のライセンス付与

ところでCSPではマイクロソフトのクラウドサービスが扱えますので、例えば既存のEAで契約して使っているO365環境に対してO365 E3を30シートCSPで購入して付け加えたい、というような要望もあり得ます。このような1つの環境にたいして、EAで購入したサブスクリプションとCSPで購入したサブスクリプションを混在させるようなこともできます

もちろんCSPで新規に顧客作成とともにAADを新規作成してしまうと別テナントになってしまうので、既存の環境とライセンス的にマージさせることはできません。マージさせたい場合には「再販業者関係の要求」のオペレーションで顧客の既存のAADと紐付けてCSPの顧客を作成し、そこに対してライセンスを付与することで可能となります。

 

パートナーポータルの権限

ところで、パートナーポータルには管理エージェント、販売代理店、ヘルプデスクエージェントという3つの顧客サポートのための権限があります。

ここで権限を持っていると、全ての顧客の全ての環境への管理権限を持ちます。残念ながら現段階では特定の顧客のみに対して権限を持つ…というようなコントロールはおそらくできません。

※本当はできるかもしれません。ここは私の理解がまだ完全ではないため、追加で確認が必要です…。

※「どの権限ならどこまでアクセスできるのか」は意図した挙動をしないことがあり要確認のステータスです(個人的に)。少なくとも「管理エージェント」であればなんでもできます。

 

ここまでのまとめ

ここまでのまとめです。

  • CSPの「顧客」は必ずAzure Active Directoryと1対1の関係となる
  • 「顧客」を新規に作成する際の選択肢は2つ。
    • 1. 新規Azure Active Directoryとともに作成する
    • 2. 既存のAzure Active Directory(顧客がすでに利用しているもの)に紐付ける
  • CSP上で「顧客」に紐付いて作成されたAzureサブスクリプションは「顧客のAzure Active Directory」が規定のディレクトリとなる(※この挙動自体時期によって変化していたようですが、今日確認したらこの挙動でした。)
  • 顧客の既存のEA契約に対して、CSPで購入したシートベースのライセンス(O365 E3等)を付与することが可能。この場合には顧客の既存のAzure Active Directoryと紐付けておく必要がある。
  • パートナーは権限を持つ人がパートナーポータルからアクセスすれば全ての顧客の管理ができる。(テナント毎のディレクトリにユーザーを作成する必要は無い)

 

Azureの利用パターン

ここからはCSPの中でも特にAzureに絞っていきます。ここが一番複雑になるので。

顧客のパターンとしては

a. すでに企業としてのAzure Active Directoryを持っている

b. まだ企業としてのAzure Active Directoryを持っていない

にわかれます。さらに、きちんとメンバーのメンテナンスをしているのかとか、オンプレミスのADと同期しているのかいないのか、唯一のID基盤なのか、他にもあるのか…等ありますが、そこは複雑になりすぎるので一旦省略します。(ごめんなさい)

そして、顧客のAzureの利用パターンとして大まかに3パターンくらいあるかなと思います。

  1. Azure…である必要すら無く、「システム」が使えればよいので、Azureにはアクセスしない。任せる。
  2. 基本的には任せるけど、何かあった時に状況は確認したい。(アクセス権がほしい)
  3. そもそも自分たちで全部管理をしたい

本来のCSPの思想は1です。この場合顧客はAzure側に権限付与の必要がないので、話はかなりシンプルです。そしてこれがCSPの考え方であるので新規に作成されたAzureサブスクリプションに対して「顧客のアカウントは権限を一切もちません」ここは重要な点です。

2や3のような要望が顧客にある場合には、Azureサブスクリプション作成後に明示的に「顧客に対して権限を付与する」作業を行う必要があります。

 

「再販業者関係の要求」を使った場合にCSPプロバイダーが持つ権限

「再販業者関係の要求」を使うとCSPプロバイダーは顧客のAADに対して権限を持つようになります。権限がなければ管理できないので当たり前なのですが、この権限が非常に強く、AADにユーザーを作成したり、ユーザーを削除したりなどもできてしまいます。CSPの思想としては全部パートナーに任せる思想なのでこのように権限が強いことは自然なのでしょうけれども、「ユーザーの毎月の変動が激しいからCSPでO365のライセンスだけ買いたい」というような要望だった場合に、ライセンス付与はしてほしいけど、AADをいじれてしまうような権限は持ってほしくない、ということも大いにあると考えられます。

環境設定後に権限を弱めることもできそうですが、未確認です。

この問題があるので、「再販業者関係の要求」をよく理解せずに乱用するのは危険だと個人的には考えています。ライセンスだけ売ってもらうつもりが、そこからセキュリティ事故に繋がったりしたら目も当てられません…。

 

権限付与パターン

ということで色々と書いてしまいましたが、このような事情が色々あり、具体的にどのように構成すればよいのか、というのはケースバイケースで考えるしかないのかなと思っています(現時点では)。

  • 新規にAADを作成しID管理を分ける
    • メリット 顧客の既存環境には何も手を入れず、独立させるのでID管理をSIer/CIerが自由にできる
    • デメリット O365のライセンスをCSPでほしいと言われると困る。別途「再販業者関係の要求」を使って別の「顧客」を作るというのが解決策になりますが、顧客のテナントが2つに分かれてしまい、管理工数が上がる。(特に、課金管理周りは周辺の設計によってはシビアな話になるかもしれません。)
    • デメリット 顧客はシステムによってIDを使い分ける必要が出てきてしまう。シングルID、シングルサインインの流れに逆行しID管理が煩雑になる。
  • 顧客がAADを持っている場合にそのAADに紐付ける
    • メリット ID管理はすでに顧客が管理しているものを利用できるため、顧客の権限付与が容易(特に2,3のパターンでメリットが大きい。)
    • メリット 顧客がAAD Premiumを利用して他要素認証を有効にしている等の場合にはそれをそのまま使える。
    • デメリット CSPプロバイダーが顧客のAADに対して強い権限を持ってしまう(※後述)

また、どちらのパターンでも、アクセスする人一人一人にIDを個別に作成するのか、共有アカウントを使うのかという分岐もあります。

共有アカウントを使ってしまったほうがID管理の面では「楽」ですが、何かあった時にだれのオペレーションなのかを追跡することができません。セキュリティ的にも大きな問題があります。

個別にIDを分ける場合にはそれを誰がどうやって作成するのか、という問題も出てきます。

現時点の私なら以下のように考えるでしょうか。

  • a-1
    • ユーザーはAzureにアクセスしないのでAADも同時に新規作成する
    • ユーザーがCSPでシートベースのライセンスを購入したい場合には別途「顧客」を「再販業者関係の要求」で作成する
  • a-2, a-3,
    • 「再販業者関係の要求」を使うべきかどうか悩みどころです。
    • 環境を確認したいお客さんが少ないのであればAADは分けておくほうが無難かなという印象です。
    • 多くの人がアクセスする可能性があり、さらにそれが「XXグループのメンバー」というような形になっていて、メンバーも頻繁に変わるようなら「再販業者関係の要求」を使うべきと思います。(顧客が許可するなら)
    • 「再販業者関係の要求」を使うとCSPプロバイダー側のID管理をどこでやるかが難しくなります。IDを作成するとお客さんのAADにIDができてしまうので。
      • 許可されるなら1IDだけ作成してそれを共用する形か。でもセキュリティ的にまずそうです。
      • マイクロソフトアカウントを人数分用意して、それを作業用IDとする…。のは動きますが、個人IDをそんなところに使っていいのか?という別の不安要素ができてしまいます。
        • マイクロソフトアカウントはすでにどこかのAADに登録されているドメインのメールアドレスでの新規登録がすでにできなくなっており、Azureにも権限付与できなくなっており、混迷を深めます。
      • 「CSPのポータルからアクセスすれば良い」というのがおそらくマイクロソフト的回答だと考えています。
        • 全てのお客さんに同じレベルでアクセスしてよいのであればこれで解決なのですが、あのお客さんにはあのチームのみが、あのお客さんには別のチームのみがアクセスできる必要がある…という話になるとここでの吸収ができなくなってしまいます。
  • b-1, b-2, b-3
    • お客さんがまだAADを持っていない状況なのでAADを新規に作成するのほぼ1択になると思います。
    • この前提ではCSPプロバイダーとして全権委任されると思いますので、ID管理もCSPプロバイダーが自由にすることになると思います。Azureのみなら。
    • お客さんがCSPでO365等シートベースのものまで手を出そうと言う時には別途考慮が必要になりますね。CSPのまま行くもよし、EAで別途環境を作るのか…。

 

ちょっとグダグダですが、すいません。汎用的にばしっと決まるものではないのでは?という印象です。

もちろんCSPはそもそもサービス形態を決めて繰り返せるようなソリューションで展開するのが一番志向されるところなので、その意味では予めCSPプロバイダーによって決めて置かれるべきものです。

色々と裏の事情や仕組みを理解した上で、対応する必要はありますね。

 

今回の内容は私としてもまだきちんと固まっていないので、同業者の方等でコメントなどありましたらもらえるとうれしいです。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

コメントを残す

メールアドレスが公開されることはありません。