スタートアップ企業のポリシー設計

この記事では、StartupExampleOrganization という架空のスタートアップ企業が Google Cloud を使用できるようにする一連のポリシーの設計方法について説明します。

スタートアップ企業は、最初からオンプレミス サーバーに投資することはせず、ネットワーク接続とラップトップという必要最小限のインフラストラクチャを出発点にするものです。スタートアップ チームは小規模で、自律性があり、迅速に行動します。どのサービスやツールを使用するかは、スタートアップ チームの判断に任されます。スタートアップ企業には、企業の IP が時期尚早に公開されるというリスクに影響されやすいという特徴もあります。

このような環境を踏まえ、スタートアップ企業の管理者としてのあなたは、セキュリティ管理に関する費用と違反を対象とした最小限のルール一式を実装することにしました。

このポリシーでは、企業が次の要件を満たしたうえで Google Cloud を使用できるようになります。

  • Google Workspace を使用して ID を管理しオフィス生産性向上ツールを利用できるようにする。
  • チームの自律性を促し、業務のスピードを高める。
  • 開発者がそれぞれ独自に使用するツールを選び、独自のリソースと環境、テストなどを作成できるようにする。
  • プライベート リポジトリとレジストリを使用する。
  • セキュリティ、コンプライアンスなどを維持するための安全策を実装する。
  • ソフトリミットを超える支出に対してアラートを出す。
  • 性善説に基づきながらも基本のセキュリティ管理は実施し、初歩的なセキュリティ管理の違反に対してアラートを出す。
  • 開発者が共有リソース一式にアクセスできるようにする。
  • 問題点を最小限に抑えて拡張できる Google Cloud 環境を設計する。

ガバナンスと表示設定

以下のセクションでは、一連の要件を満たすために StartupExampleOrganization が使用できる Google Cloud のさまざまな手法について説明します。

ID 管理

StartupExampleOrganization 社の要件は次のとおりです。

  • Google Workspace を使用して ID を管理しオフィス生産性向上ツールを利用できるようにする。

Identity and Access Management(IAM)を使用すると、メンバーにアクセス権を付与することで、Google Cloud リソースへのアクセス権を付与できます。メンバーには次のタイプがあります。

  • Google アカウント
  • サービス アカウント
  • Google グループ
  • Google Workspace のドメイン(Google Workspace アカウントをお持ちの場合、Google ワークスペース ドメインが存在することを意味します。詳細については、このヘルプトピックをご覧ください)。

次の図に示すように、Google Workspace アカウントは Google Cloud リソース階層本質的に関係しています。

リソース階層

Google Cloud は、組織リソースがなくても使用できますが、企業の規模にかかわらず、組織リソースの枠内で Google Cloud リソースを設定することをおすすめします。組織管理者が、企業のアセットを完全に把握して管理します。

StartupExampleOrganization 管理者はすでに Google Workspace ユーザーであるため、組織リソースを使い始めるための前提条件をすでに満たしています。Google Workspace のアカウントに、Google Cloud リソースにアクセスするための権限を付与できます。

組織の設定

StartupExampleOrganization の要件は次のとおりです。

  • 開発者が各自で使用するツールを選び、独自のリソースと環境を用意し、自由に試行が行えるようにする。
  • 開発者が共有リソース一式にアクセスできるようにする。
  • 問題点を最小限に抑えて拡張できる Google Cloud 環境を設計する。

組織リソースが用意されていれば、組織をリソース階層にマップできます。この階層編成では、プロジェクトやその他のフォルダのコンテナとしてクラウド フォルダを使用できます。Cloud Folders を使用すると、ユーザーはフォルダでプロジェクトをグループ化でき、リソースやポリシーの大規模な管理が可能になります。この構造では、チームとチームが使用するアプリ(プロジェクトにマップされます)が並列に扱われ、チームの下にアプリがグループ化されます。次の図に概要を示します。

組織の設定

クラウド フォルダを使用すると、フォルダレベルでアクセス管理ポリシーを管理できます。特定のフォルダに含まれるすべてのプロジェクトは、そのフォルダのポリシーを継承します。

StartupExampleOrganization では、社内の開発者が仕事を迅速にこなせるようにしたいと考えています。また、個人情報(PII)の保護をはじめ、ビジネスに必要となる基本的なセキュリティ要件とコンプライアンス要件を拡大して準拠するためのフレームワークの実装も目指しています。組織リソースを使用すれば、リソースを一元管理しながらも、各チームがそれぞれのフォルダとプロジェクトを所有できるようになります。たとえば、各チームが独自にアプリケーションのデプロイ方法やモニタリングの実装方法を決定できます。

プロジェクト間でリソースを共有するには、共有 Virtual Private Cloud(VPC)ホスト プロジェクトのサービス プロジェクトでもある、共有リソース プロジェクトを作成します。詳細については、ネットワークの構成とセキュリティ管理をご覧ください。

継続的インテグレーション / 継続的デプロイ パイプライン(CI / CD)などの自動化プロセスで使用するサービス アカウントをホストするには、リソース プロジェクトを使用します。このプロジェクト内には、共有アセット(設定スクリプトなど)と共有データベースも配置できます。その上で、リソース プロジェクトを管理できるユーザーを制限できます。

企業の標準に従っていない設定オプションを、組織ポリシーによって禁止することで、安全策を実装できます。たとえば、誰が作成したかにかかわらず、仮想マシン(VM)を外部 IP で使用できないよう保護することが可能です。必要に応じて、プロジェクトごとにポリシーをオーバーライドできます。階層の組織レベルで権限が付与されるサービス アカウントを実装すると、専用プロジェクトから、インベントリや指標をモニタリングしたり、リスクがある場合にアラートを出したり、集約したりできます。

システムの運用

StartupExampleOrganization の要件は次のとおりです。

  • チームの自律性を促し、業務のスピードを高める。
  • 開発者がそれぞれ独自に使用するツールを選び、独自のリソースと環境、テストなどを作成できるようにする。
  • プライベート リポジトリとレジストリを使用する。
  • 開発者が共有リソース一式にアクセスできるようにする。

StartupExampleOrganization の創設者は、自社の IP を保護する必要性を認識しています。プライベート リポジトリとコンテナ レジストリの実装が役に立ちます。Google Cloud が提供する完全ホスト型プライベート Git リポジトリでは、IAM によってアクセスを制限できます。Container Registry は、Docker イメージ用の Cloud Storage を使用した非公開レジストリです。Container Registry を使用して適切な権限を付与し、コンテナを組織のメンバーに限定できます。

サービス アカウントを利用すると、自動化プロセスが容易になります。自動化は常に重要ですが、アジリティが鍵となる場合、その重要性はさらに高まります。自動化を進めるほど、より多くのリソースをアプリ開発に集中させることができます。

Infrastructure as Code の概念を導入してクラウド環境を自動化すると、プロジェクトおよび関連する管理のセットアップをプログラムによって繰り返し行えるようになります。さらに、使用するスクリプトやテンプレートのバージョン管理も行えるため、Google Cloud 環境の構成をコードと同じように扱って、バージョン管理のメリットすべてを活用できます。

Cloud Deployment Manager を使用すると、適切なリソースと IAM ポリシーを含むプロジェクトを自動的に作成できます。テンプレートをセルフサービス システムの一部として使用できます。

組織が成長するにつれ、このような繰り返し可能なプロセスによって、新しいチームが迅速に成長し、成果を出せるようになります。

組織のセキュリティ管理

StartupExampleOrganization 社の要件は次のとおりです。

  • セキュリティ、コンプライアンスなどを維持するための方策を用意する。
  • 性善説に基づきながらも基本のセキュリティ管理は実施し、初歩的なセキュリティ管理の違反に対してアラートを出す。

組織ポリシー サービスを使用すると、StartupExampleOrganization のクラウド リソースをプログラムで一元管理できます。このサービスでは、許可された構成をクラウド リソースの階層全体に簡単に適用できます。ここでポリシーとは、クラウド リソースの組織レベルの構成を制御できる組織のポリシーを意味します。

組織ポリシーには次の利点があります。

  • 組織のリソースの使用方法に制限を構成することで、リソースを集中管理できます。
  • プロジェクト、フォルダ、組織ごとにポリシーを設定できます。
  • ポリシーはリソース階層の下に継承され、ポリシー管理者は、組織ポリシーが設定可能なあらゆるレベルで、ポリシーをオーバーライドできます。
  • リソースのオーナーではなく、組織のポリシー管理者がポリシーを管理します。つまり、個々のユーザーやプロジェクト オーナーは、組織のポリシーをオーバーライドできません。

リソースの管理

組織のポリシーを実装することで、Google Cloud の信頼境界線(フォルダ、プロジェクト、またはその他の組織レベル)内で利用できるリソースを規制できます。

  • IAM では、誰(ID)がどのリソースに対してどのようなアクセス権(ロール)を持つかを定義することによって、アクセス制御を管理できます。誰がどの種類のアクセス権を持つかを定義するステートメントの集合である IAM ポリシーを作成することによって、ユーザーにロールを付与できます。ポリシーをリソースに接続すると、リソースにアクセスするたびにアクセス制御が適用されます。
  • Resource Manager は、アクセス制御ポリシーと組織のポリシーの接続ポイントを提供し、継承を可能にします。Resource Manager API を使用すると、組織、フォルダ、プロジェクトの操作が可能になります。
  • どのアクセス制御を適用するか、誰にアクセス権限を付与するか、どのような場合に最小限の権限を適用するかを、常に慎重に検討する必要があります。

最初に、成長に伴って管理を強化できるようにするためのフレームワークを設定します。共有リソース プロジェクトに対する制限された権限をセットアップし、アクセスを組織の管理者役割、ネットワーク役割、セキュリティ役割に制限します。

機能上のロール

StartupExampleOrganization の機能上のロールを適切な IAM のロールに対応付ける必要があります。

グループを使用してユーザーを管理することで、機能を実行できるユーザーを変更できます。つまり、ポリシーを更新する代わりに、グループ メンバーシップを編集できます。StartupExampleOrganization 固有の用語を使用して、機能上の役割を反映した名前をグループに指定します。組織の成長に応じて、ネットワーク管理者とセキュリティ管理者からなる専用チームとして作成したグループのメンバーを減らすこともできます。

次に示す IAM ポリシーの例は、StartupExampleOrganization が要件を満たすのに役立ちます。

IAM ポリシーの説明 機能
ポリシーを適用するリソース: 組織

付与するロール: ネットワーク管理者共有 VPCセキュリティ管理者

バインドされるメンバー: セキュリティとネットワークの管理チーム
中央のチームがネットワークおよびセキュリティ管理の両方を制御します。すべてのプロジェクトで 1 つの VPC ネットワークを共有します。

ネットワーク管理者共有 VPC 管理者の両方のロールを割り当てると、ネットワーク リソースの一元管理が可能になります。

セキュリティ管理者のロールは、ファイアウォール ルールと SSL 証明書の管理に必要な権限を提供します。

命名規則とラベル付け

OurStartupOrg の要件は次のとおりです。

  • チームと、チームが開発したサービスの間でクロスチャージを分配する。
  • OurStartupOrg の Google Cloud アカウントで発生したアクティビティを監視する。

ラベルは、多数の Google Cloud リソースでサポートされている Key-Value ペアです。OurStartupOrg では、ラベルを使用して、エクスポートされた課金データ内の費用を、複数のチームやチームが開発している製品にわたって追跡できます。ラベルを使用してフィルタリングとグループ化を行うことにより、OurStartupOrg では Cloud Monitoring リソース グループを使用して、チームごとまたはアプリケーションごとのアクティビティをモニタリングできます。

費用の追跡と理解

StartupExampleOrganization の要件は次のとおりです。

  • ソフトリミットを超える支出に対してアラートを出す。

1 つの請求先アカウントを Resource Manager および請求機能と組み合わせて実装するだけで、StartupExampleOrganization の要件を満たすことができます。請求機能には次のものが含まれます。

  • リソースを編成するためのプロジェクト。コストはプロジェクトごとに表示されます。請求書エクスポートに、プロジェクト ID が含まれます。
  • 追加のグループ情報を表すラベル(environment=test など)によるプロジェクトのアノテーション。ラベルを請求書エクスポートに含めることで、コストをより詳細に分析できます。ラベルは変更されることもありますが、有用です。
  • Project Name または ID へのコストセンターのエンコード。これにより、容易にコストをコストセンターに遡って追跡できるようになります。
  • Cloud Billing レポート。使用料金を一目で把握でき、傾向を見つけて分析できます。
  • BigQuery に直接エクスポートされる課金データ。詳細な分析が可能になります。

次の図は、Resource Manager と組み合わせて実装された単一の請求先アカウントを示しています。

請求体系

StartupExampleOrganization では、1 人の担当者が請求書の支払いを処理します。このポリシーを適用すると、開発者は請求先アカウントを使用することはできても、新しい請求先アカウントを追加で設定することはできません。課金 IAM の役割を使用すると、開発者がこのシナリオに適切な権限を設定できるようになります。

請求書のエクスポートはコストを分析するための手段です。最初のうちは StartupExampleOrganization にとってコスト分析は優先度の高い要件ではないかもしれません。しかし、今後成長するにつれ、コスト分析が必要になる可能性はあります。ここで基本的な設定ルールを実装しておくことで、後での実装が容易になります。

課金指標に対してアラートを出すには、請求先アカウントまたは個々のプロジェクトに対して予算とアラートを設定します。予算は特定の金額に設定することも、前の月の支出に合わせることもできます。また、利用額が予算の一定の割合を超えたことを課金管理者に通知するアラートを作成することもできます。スタートアップ企業のお客様の場合、予算にはまだ変更の余地があります。したがって、予算を超えたとしても使用額には影響しません。

プロジェクトごとに予算を適用できます。プロジェクト別に予算を組む場合、必要に応じて柔軟に特定のプロジェクトの予算額を上げることができます。また、プロジェクトごとにアラートを設定できます。たとえば、BigQuery を使用するプロジェクトには、単にインスタンスを使用するだけのプロジェクトよりも多くの予算が必要です。

組織管理と ID 管理ポリシーの提案

次の図に、StartupExampleOrganization の組織ポリシー案を示します。

組織ポリシー

上の図には、6 つの主な特長があります。

  1. 「ガードレール」を設定するための組織ポリシー。

  2. 組織全体での徴収とモニタリングを実行しているサービス アカウント。

  3. リソースを持つ部門用のフォルダ。

  4. チーム、アプリケーション、環境、テストケース用のプロジェクト。

  5. IAM を ID 管理に使用する。

  6. 中央管理チームに管理され、最小限の特権で他の部門と共有される共有インフラストラクチャ リソース。

ネットワークの構成とセキュリティ管理

StartupExampleOrganization の要件は次のとおりです。

  • 開発者が共有リソース一式にアクセスできるようにする。

  • 問題点を最小限に抑えて拡張できる Google Cloud 環境を設計する。

まず、StartupExampleOrganization には常設オフィスがありません。ワークロードにインターネット経由のルーティングで得られるレイテンシより低いレイテンシが必要な場合は、オフィスを構える場所を見つけた後、Cloud Interconnect を使用して Google Cloud に接続します。

共有 VPC

共有 VPC を使用すると、中央のホスト プロジェクトから VPC ネットワークやサブネットなどの一般的なネットワーク リソースを管理できます。これらのリソースには、他のプロジェクトもアクセスできます。この設定と IAM 管理によって、中央ネットワークの管理が簡単になります。

共有 VPC を使用すると、複数のプロジェクトにまたがる共通のプライベート RFC 1918 IP 空間などの VPC ネットワークを利用できます。この VPC ネットワークまたはそのサブネットに、あらゆるプロジェクトのインスタンスを追加できます。

共有 VPC を実装することで VPC ネットワークを一元管理できますが、StartupExampleOrganization オフィスから共有 VPC ホストへの VPN をセットアップすることで、管理を単純化することもできます。VPN では、共有 VPC ホスト上のサービス プロジェクトに簡単にアクセスできます。

最初から柔軟なフレームワークをセットアップしておけば、StartupExampleOrganization はネットワーク リソースを共有し、中央のネットワークを管理して、企業の成長に対応できます。

IAM ネットワークの役割

機能 必要な IAM ポリシーの説明
限られた数のユーザーが、ネットワークとセキュリティ管理の両方を制御します。すべてのプロジェクトで 1 つの VPC ネットワークを共有します。
  • ベスト プラクティスに従い、ネットワーキングとセキュリティを一元管理するユーザーの ID を含むグループを設定します。このグループは、この要件を満たすために必要な IAM ポリシーで使用します。
  • 共有 VPC を使用すると、一元管理されたチームをマッピングしてネットワークの設定を管理できます。
  • ネットワーク管理者の役割と共有 VPC 管理者XPNAdmin)の役割の両方をクラウド リソース階層の組織レベルのグループに割り当てます。さらに、この管理グループに組織レベルのセキュリティ管理者のロールを付与すると、ファイアウォール ルールや SSL 証明書の管理に必要な権限が与えられます。

次の図に、StartupExampleOrganization の要件を満たすネットワーク モデルを示します。

開発者が共有リソース一式にアクセスできるようにするネットワーク モデル

上の図には、2 つの主な特長があります。

  1. 中央の管理者とサービス アカウントが、すべてのテンプレート化されたリソース変更を行う。

  2. 共有リソースが別のサブネットにある。

ファイアウォール ルール

ファイアウォール ルールは、ソース サブネットとターゲット サブネットの間、または特定のサービス アカウントを使用するかまたはタグ付けされたインスタンス間のトラフィックを管理します。これらのルールは、開発環境、テスト環境、本番環境の間で十分なゲートを確保するために必要な制御を提供します。

参照

要件 参照
ID 管理
組織の設定
システム オペレーション
課金
ネットワークおよびセキュリティ管理

次のステップ