Google Cloud コンソールと管理コンソール

※この投稿は米国時間 2022 年 5 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

IT 業界でなんらかの仕事をしたことがある方は、テクノロジーがどんな速さで変化しているかをよくご存じでしょう。「クラウド ネイティブ」、「コンテナ」、「コードとしてのインフラストラクチャ」といった流行の業界用語を耳にしたことがあるでしょう。

クラウド

そして「クラウド」、すべてを制する業界用語です。異なるクラウド プラットフォームまたはオンプレミス環境を使用している場合、最初は少々怖気づいたり、混乱するかもしれません。続きを読み、Google Cloud アカウントとリソースを設定して、保護する方法について学んでください。

2 つのコンソール

Google Cloud にはお客様のアカウントとリソースを保護できる 2 つのコンソールがあります。

1. 管理コンソール: ユーザー、グループ、アクセス コントロール、Google Workspace ドメインを管理できます。
   
   

2. Cloud コンソール: Identity and Access Management（IAM）を介してきめ細かいアクセス コントロールを実装する、API とサービスを有効化する、仮想マシンやネットワーキングなどのインフラストラクチャとリソースを作成、管理する、といったことを行えます。

この 2 つのポータルは両方ともリソースにアクセスできるユーザーを管理するうえで非常に重要なので、2 つを混同してしまう可能性があります。この 2 つの違いとそれぞれの機能について確認しましょう。

アーキテクト

違いを理解できるようにするために、架空の主人公である羊の Ramalton の助けを借りましょう。羊の世界に住む Ramalton は特に Ramsville 市向けにアプリとソフトウェアを開発する Big Horn Inc. と呼ばれる SaaS 企業に就職したばかりです。同社は IT 部門を拡大し、Google Cloud を使用してアプリケーションとインフラストラクチャが安全かつより信頼できるようにするためクラウド アーキテクトを雇用したのです。

Ramalton の最初の仕事は同社の Google Cloud アカウントを設定することでした。そこで羊たちの執行委員会（EBOR）と会議を行い、基本的なことから始めると決めました。特権管理者アカウントの設定と Identity and Access Management（IAM）についての短期集中コースを実施しました。

Ramalton は特権管理者が取消不能な管理者権限を持つことについて詳細に説明しました。このオプションに一部の重役は最初ナーバスになり、「一匹の従業員（羊）に与える権限にしては重すぎる」と言いました。Ramalton は特権管理者アカウントは組織の日常的な管理に使用されるものではなく、そちらの用途には組織管理者アカウントを設定すると保証しました。次に羊たちが特定のユーザー、グループ、または ID に対し、特定のクラウド リソースや機能へのアクセス権限を付与できる IAM のしくみについて EBOR に説明しました。IAM により羊たちは読み取り、編集、変更をできるユーザーを制限することで、クラウド インフラストラクチャを安全に保てるようになります。

主人公の Ramalton に話を戻しましょう。ミーティングはうまくいったようです。EBOR は深い感銘を受けました。Google Cloud アカウントをすぐに設定することになりました。

Ramalton の次のタスクは Big Horn のアカウントを設定するための特権管理者を作成し、ユーザーとグループを作成することです。Ramalton はアカウントの初期設定が管理コンソールからできることを知っていました。

管理コンソールとは

管理コンソールは Ramalton のような管理者がユーザーの追加、グループの作成、デバイスの管理、請求先の構成、セキュリティ設定の管理を行う場所です。これらの Google Cloud 管理タスクはすべて 1 か所から行うことができます。

Ramalton は同社がすでに Google Workspace を使用していることを知っていたため、組織を設定して Google Cloud アカウントを管理できるようにすることが最適だと思いました。

組織とは

組織について説明します。組織は Google Cloud リソース階層のルートノードです。つまりすべてのフォルダ、プロジェクト、リソースのトップに存在することを意味しています。組織レベルで作られた既存のポリシーや制限はその下のフォルダ、プロジェクト、リソースに継承されます。組織は Google Workspace で利用できます。Google Cloud のお客様は Cloud Identity を通じて利用できます。ない場合は、すぐに組織を作成できます。

話を戻しましょう。次は同社の請求先アカウントとユーザーおよびグループの設定です。

請求先アカウントとは

Google Cloud コンソールで請求先アカウントを設定できます。これにより新しいサービスを作成したり、その支払いをしたり、組織内のどのユーザーに請求情報の閲覧権限または管理者権限を付与するか決めることができます。閲覧権限を持つユーザーは請求情報の詳細の閲覧のみができ、管理者権限を持つ場合はアカウントの請求情報の変更 / 調整を行うことができます。適切な権限を必要に応じて付与するため、各ユーザーの責任を把握することが重要です。Google Maps Platform のお客様であればすでに請求先アカウントを作成している可能性があります。

これで請求関連の設定ができました。次に Ramalton は管理コンソールでユーザーとグループを作成する必要があります。

ユーザー

ユーザーとは、特定のタスクを実行したり、アカウントの特定のリソースにアクセスできるようにアクセス権限を与える人物を指します。組織では、ユーザーになる人を招待できます。

グループ

グループはユーザーとその権限を管理する一つの手法です。通常は、携わるタスク、やるべきこと、通常アクセスするリソースに基づいてユーザーをグループに分けます。グループにはロール（権限とも呼ばれる）を付与することができます。たとえば、コンピューティングのリソースに対する読み取り専用権限のみが必要なユーザーが何人かいる場合は、グループにまとめて compute.viewer ロールを付与します。そのグループの各ユーザーは compute.viewer 権限を継承できるようになります。

午後のおやつの時間になりました。Ramalton は自販機で塩塊と牧草チップを買うことにしました。Ramalton のお気に入りです。Ramalton は空想しながら、この会社の Google Cloud アカウントのセキュリティを強化できる方法について考えました。そしていくつかのガードレールを設定するのがよい方法だと思いました。

特定のユーザーのみが同社アカウントの特定サービスへのアクセス権限を持つようにしたかったのです。Ramalton は組織のポリシーに関する記事を見つけました。この記事では羊たちのアカウント内でガバナンスを実現できるようにする高レベルなルールを設定する方法について説明していました。組織のポリシーによって、リソースの作成を特定のリージョンに限定したり、有効にできる API を制限したり、リソースの作成を特定の構成のみに限定するといったことができるようになります。

Ramalton は組織、請求先、ユーザー、グループ、組織ポリシーの設定をすべて終えました。これでアカウントでインフラストラクチャを設定できるようになったので、Cloud コンソールにログインしました。

Cloud コンソールとは

Cloud コンソールは Google Cloud VM、ストレージ バケットなどのすべての作成、モニタリング、変更のメイン ゲートウェイであり、そこからさまざまなサービスにアクセスし、プロビジョニングできます。Cloud コンソール内には、各種サービスをカテゴリに基づいて論理的にグループ化したナビゲーション メニューがあり、アプリケーションとそれを実行するインフラストラクチャを構成・保護するために必要なツールと設定が提供されています。

VPC 

Ramalton はネットワーキング チームとセキュリティ チームとのミーティングで取ったメモが書かれているホワイトボードを確認しました。ミーティングで Virtual Private Cloud（VPC）を設定する必要性について話し合ったことを思い出しました。インフラストラクチャ ネットワーキングとセキュリティの観点から、リソースを構築するためには 1 つ以上の VPCが必要になります。VPC によってクラウド内に独自のプライベート ネットワークを作成し、ルーティングを設定してファイアウォール ルールを定義できるようになります。

VPC は自分のリソースを構築できる独自のネットワーキングがある Google データセンター内の独自のセクションのようなものです。Google Cloud ではリソースをグループ化するために最初の「デフォルト」VPC がデフォルトで提供されます。Google Cloud のベスト プラクティスは、独自の VPC を設定して構成し、独自のニーズに合わせてネットワークを微調整して、ネットワークを完全に制御できるようにすることです。

ワークロードの認証

Ramalton のオフィスのドアを誰かが蹄でドンドンとノックしています。がっしりした声で「調子はどうだい、Ramalton」という声が聞こえ、それは上司の Ramsey でした。Ramsey は片方の角が曲がりはじめて、帽子を探すのに苦労している話を延々としはじめました。Ramalton に愚痴った後、会話は彼らのアプリの一つについてに変わりました。Big Horn のオンプレミス データセンターには、Sheepdreams と呼ばれるアプリケーションがあります。Sheepdreams は月を超えてジャンプするすべての子羊を追跡します。このアプリは Big Horn の最大の収入源であるため、同社にとってミッション クリティカルになります。

これは何百万人もの人々の安眠に貢献しており、これがなければ今ある世界は絶望の道をたどることになるかもしれません。Ramalton はオンプレミス データベースに Google Cloud アカウントでワークロードへのアクセス権限を付与する必要があります。州の規定のため、顧客データはオンプレミスで保存する必要があります。有効期間が長いサービスキーはシークレット管理の面で懸念があるので使いたくありません。Ramalton は Google Cloud ドキュメントを読んだあと、Workload Identity 連携が最適なのではないかと考えました。

現在のオンプレミス ID プロバイダを使用して Google Cloud のショート トークン サービス（STS）を呼び出し、アクセス トークンの ID を交換できます。アクセス トークンは Google Cloud アカウント内で構成されたサービス アカウントの権限を借用します。このオプションにより、頭を悩ますサービスキーの管理と安全対策が回避できます。

Workload Identity 連携によって、有効期間が長いサービス アカウント キーではなく有効期間の短いアクセス権を提供することで、アプリケーションの外部ワークロードが Google Cloud のワークロードへのアクセス権限を安全に取得できるようになります。

数か月が経ち、Ramalton は Google Cloud への適応と利用を順調に拡大しています。ある日、新しいマネージャーの Hamilton と話している際に、ソーシャル メディアを席巻している最新の強靭な角チャレンジについて話し合いました。Hamilton は世界中の羊が写真を投稿し、自らの角でどのようなダメージを与えることができるのかを示せるアプリケーションを作るというアイデアを出しました。このアイデアは Big Horn Inc. に新しい収益の流れをもたらす可能性があります。

アプリケーションには、データベース、ウェブサーバー、永続ストレージ、ロード バランシングが必要になります。オーバーヘッドが少なく、ポータビリティが増すコンテナの活用が考慮されました。Ramalton は、Google Cloud Next 2018 の YouTube 動画を視聴したことを思い出しました。動画ではコンテナ化されたワークロードを迅速かつ簡単に作成し、管理する方法として Google Kubernetes Engine（GKE）をハイライトしていました。コンテナ オーケストレーション ツールとして、コンテナをデプロイ、管理、スケールできることから、Ramalton はこれがプロジェクトに最適だと思いました。Google Kubernetes Engine などのツールによって安全にクラウド ネイティブのアプリケーションを作成し、デプロイできます。

すべてを保護する

コロナ禍の影響で、Ramalton は何か月も在宅勤務しています。最後の新型コロナワクチンを接種したら、オフィスに戻れると思っています。オフィスに戻れるようになる前に、新しい CISO のオフィスに呼ばれました。CISO は Ramalton の業績と Google Cloud の知識に感銘を受け、Big Horn のセキュリティ慣行をモダナイズするための新しいプロジェクトをサポートしてほしいと伝えました、Big Horn のコンピューティング リソースが最近侵害され、攻撃者が同社の認証情報へのアクセスを得て、クリプトマイニングを始めたそうです。

Ramir は Identity-Aware Proxy（IAP）を使用して Compute Engine インスタンスで実行されるアプリへのアクセスを確認し、ID 制御を使用してアプリを保護するよう Ramalton に提案しました。また Google BeyondCorp Enterprise を利用すれば、実行環境がオンプレミスかパブリック クラウドかにかかわらず、重要なアプリケーションやサービスへのアクセス権限を付与できます。BeyondCorp Enterprise により、リクエストに由来するネットワークではなく、リクエストのコンテキストを用いて、リクエストごとにアクセス権限を決定できるようになります。BeyondCorp Enterprise は柔軟性が高くスケーラブルです。そしてなにより、従来の境界モデルよりも安全です。また既存のデバイス管理システムと簡単に統合して、コンテキストに基づいたアクセス権限に関する決定を正しく行うことができます。

使ってみる

2 つのコンソールの違いを見極め、Google Cloud アカウントとリソースを自由に扱い、保護する方法についてご紹介しました。Google Cloud アカウントはこちらからご登録いただけます。クラウドをぜひご活用ください。