クラウドにおけるアカウント管理

アクセンチュア・クラウド・ダイアリーズをご覧頂きありがとうございます。クラウド推進事業本部の門畑と申します。今回はクラウドサービス導入に際して、最も基本的なクラウド利用ポリシーとなる、クラウドサービスのアカウント管理の勘所について紹介いたします。

アカウント管理とは
クラウドサービスを利用するにあたって検討しなくてはならない必須項目として、IPアドレス体系や仮想ネットワーク(*1)の設計等のネットワーク、ファイアーウォール設定やデータ暗号化等のセキュリティ、サービスレベル・非機能、運用・監視等があります。それらの項目を検討するうえでの前提となる、最も基本的な項目がアカウント管理となります。

(*1)仮想ネットワーク：Amazon Web Services (AWS)、Google Cloud Platform (GCP)におけるVirtual Private Cloud、Microsoft Azure　(Azure)、におけるVirtual Networkであり、クラウド環境において論理的に分離されたネットワーク
参考情報：

• AWS VPC: https://aws.amazon.com/jp/vpc/
• Azure Vnet: https://azure.microsoft.com/ja-jp/services/virtual-network/
• GCP VPC: https://cloud.google.com/compute/docs/vpc/?authuser=19&hl=ja

アカウントとは大辞林第三版によると「③OS やネットワークを通してコンピューターを利用するための固有の ID ナンバーやその権利。ユーザーの識別や、個別の情報の管理のために用いられる。」という意味です。パソコンのログイン画面において入力するユーザー名が身近な例としてあげられると思います。クラウドサービスにおけるアカウント管理も同様に、誰(組織、チーム、個人等)が、どのリソースに対して、どの権限(完全なコントロール、一部制限)でアクセスできるかを管理することになります。

さて、アカウント管理においてまず検討しなくてはならないのは、契約単位の管理方針、即ち、 AWS、 Azure、GCPといった主要クラウドサービスプロバイダーにおけるAWSアカウント、Azureサブスクリプション、GCPプロジェクト(*2)の管理方針です。便宜上、今回のブログにおいては契約単位を「ルートアカウント」と称し管理方針の説明をいたします。

(*2)参考情報：

• AWSアカウント: https://docs.aws.amazon.com/ja_jp/polly/latest/dg/setting-up.html
• Azureサブスクリプション: https://blogs.msdn.microsoft.com/daisukei/2015/05/29/azure-accountsubscription/
• GCPプロジェクト: https://cloud.google.com/docs/overview/?hl=ja

ルートアカウント管理方針
クラウドサービスを利用する際に、まず最初にルートアカウントを作成することになります。管理方針の論点は、①単一とするのか、それとも複数とするのかというルートアカウント分割の基本方針と、②どのような観点で複数に分割するのかを、設計・構築の容易性、運用の容易性や拡張性等を鑑みて検討することです。

クラウドサービスを利用する組織が小さい場合や、クラウドサービスのProof of Concept（PoC)を実施する場合等、利用規模が小さくかつ迅速にクラウド利用を行う場合は、単一のルートアカウントの利用が望ましいでしょう。一方で、組織が大きい場合や、複数の組織や関連会社でクラウドサービスを利用する場合等、利用規模が大きくかつ拡張性が求められる場合は、複数のルートアカウントを利用することが推奨されます。ここで、拡張性の観点をあげている理由は、AWS、Azure、 GCPそれぞれにおいてルートアカウント内に利用できるリソースの制限があるためです。ルートアカウント数には上限がないため、分割することにより拡張性を高めることが可能となります(*3)。なお、利用するクラウドサービスプロバイダー毎にリソースの上限値に違いがあります(*4)。

(*3)GCPについては上限数が存在、上限緩和の申請可能
(*4)リソース制限の参考情報：

• AWS: https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html
• Azure: https://docs.microsoft.com/ja-jp/azure/azure-subscription-service-limits
• GCP: コンソール画面でリージョン毎の上限値の確認が可能

次に、ルートアカウントを複数に分割する場合に、その分割単位をどうするかを検討することが必要となります。クラウドサービスの利用企業の用途によって、以下のような分割例があります。

1. 1. システム毎に分割
      システム規模が大きく、システム毎に管理者を明確に分離したい場合
      
      
   2. 利用用途/組織毎に分割
      データ分析基盤としてクラウドサービスを利用する際に、分析対象や分析チーム毎にデータの加工・蓄積・分析の一連の作業を明確に分離したい場合
      
      
   3. 環境毎に分割
      環境毎にセキュリティ方針や利用方針を明確に分離したい場合
      
      
   4. 環境かつシステム毎に分割
      上記1、3の両方の要件がある場合
      
      

ルートアカウントが単一である場合、設計・構築が容易で迅速な利用が可能である一方で、責任所在が明確ではないというデメリットがあります。ルートアカウントが複数である場合、拡張性は高くなり、また管理の責任所在が明確になるといったメリットを享受できます。一方でデメリットとして、アカウント毎のセキュリティポリシー設定や課金管理のための関係者とのルール作り等の設計・構築作業が複雑となります。また、監査証跡を取得する際に複数のルートアカウントからの取得が必要となる等、運用が煩雑となることも考えられます。

従って、ルートアカウント管理方針は、分割数を増やすことにより拡張性を高められる一方で、設計・構築作業の複雑さ、運用上の煩雑さといったトレードオフの関係となることに注意し、クラウド利用用途、利用組織、運用方針を考慮したうえで決定することが必要となります。様々な軸と関係者が存在することにより方針検討が困難な場合は、上述の1.のようなシステム管理単位で分割する方針とするのも一つの方法かもしれません。より細かい粒度での管理が必要になる場合は、仮想ネットワークによる分割と、利用ユーザーの権限管理でアクセス制御することは可能となります。

まとめ

• アカウント管理はクラウドサービスを利用するうえで、最も基本となる利用ポリシー
• 契約単位であるルートアカウントの管理方針の論点は、①単一とするのか、それとも複数とするのか、②複数とする場合、どのような観点で複数に分割するのか
• ルートアカウント管理は、分割数を増やすことによる高拡張性と、設計・構築作業の複雑さ、運用上の煩雑さのトレードオフの関係であるため、クラウド利用用途、利用組織、運用方針を考慮したうえで決定することが必要