概要
Google Cloudを使用する上で欠かせないのが、セキュリティ対策です。
ただし、初期設定の段階で、まずは各種必要なリソースの役割について理解していないと検討できるセキュリティ対策を考えることができません。
今回は、 Google Cloudを初めて利用するといった方向けに初期構築時にどのようなリソースが必要なのかを解説していきます。
Google アカウント
一言でいうとユーザーIDになります。
Google Cloudにログインする場合には、そのためのIAMユーザーが必要になりますが、これはその他Google サービス（YoutubeやGmail） と同じユーザアカウントを使用することになります。
皆様も、YouTubeやGmailを使用するときに、1つのアカウント単位でログインをしてメールボックスや動画を見ると思いますが、それと同じような感覚でGoogle Cloudにもログインすることになります。
【Google アカウント】
また、もし企業で運用する場合には、Google Cloud Identity というIDPを 使用して、その中にIAMユーザーを作成していきます。
この辺の概念は、どのようにユーザーを管理していくかにより、IDPの利用可否が決定されますが、単純にGoogle アカウントを考えるときは、皆様が普段無料で使う@gmail.comを想像していただければ、イメージしやすいと思います。
Google Cloud プロジェクト
こちらは、Googleクラウドを使用する上で利用する箱のような概念です。
実際にBigQueryやCloud Storage、ComputeEngineなどのリソースを作成していくので、リソースをまとめる1つの単位と考えることもできます。
こちらはGoogle Cloud 固有のものになりますので、他のGoogleサービスには関係ありません。
プロジェクトは環境ごとに作成するものであり、 開発、本番、テスト等のようなアプリケーションを開発する時の各ステージを区別するために役立ちます。
これにより、リソースの管理が容易になり、異なる環境間での設定の混在を避けることができます。
また、事項でも触れますが、プロジェクトごとに課金情報やアクセス権限を設定することができるため、セキュリティとコスト管理の面でもメリットがあります。
【プロジェクトの役割】
請求先アカウント
こちらは、Googleクラウドを利用する上で、支払い先を登録するものになります。
通常、Googleクラウドの利用開始するときにクレジットカードの登録を行いますが、そのクレジットカードの情報を登録するのがこの請求先アカウントになります。
【請求先アカウントの関係性】
またプロジェクトごとに紐付けるものであり、先程の説明でも触れましたが、各プロジェクトで別の請求先アカウントに紐付けることにより請求の単位を分けることができます。
また、リセラー（再販パートナー）を挟んで、Google Cloud を利用する場合には少し仕組みが変わりますが、基本的には1つのプロジェクトに、1つの請求先アカウントが紐付くという関係性は変わりません。
ここまで紹介した「Googleアカウント、Google Cloudプロジェクト、請求先アカウント」この3つがあれば、Google Cloudの利用を開始することができます。
次の組織からは、企業（団体）でGoogle Cloudを運営する上で必要な追加のリソースの解説をしていきます。
組織
Google Cloudでいう組織とは、ドメイン（@example.classmethod.xyz...etc）と1対1で存在する概念になります。
組織の役割としては、グループごとのプロジェクト管理や組織的なポリシーの統一、そして権限管理が挙げられます。
よって、組織を利用しないでGoogle Cloudを運用すると、セキュリティー的に脆弱な状態で管理することになってしまいます。
【組織あり/なし】
（個人でGoogleクラウドを使用して開発することになると、プロジェクトの数や開発する人数も限られてくるので、この限りではありません。）
あくまでも、企業や団体で多くのIAMユーザーやプロジェクトを管理する場合に、組織というリソースを使用することにより統一的な管理が実現できる、そういったイメージです。
ーーーーーーーーーーーーーーーーーーーー
【使用例】
①クラスメソッドという組織で外部IP（グローバルIP）を新規に作成するVM（CoputeEngine）に付与させたくない。
↓
②ポリシーを一元的に組織に対して適応させる。
↓
③その組織配下で作成したプロジェクトでは、VMに外部IPを付与することができなくなる。
ーーーーーーーーーーーーーーーーーーーー
【Google Cloudの組織ポリシー】
グローバルIPは外部に漏れるとDDoSなどのセキュリティ攻撃の対象になり得る危険性があります。
どこにどのリソースがあり、どのように管理されているのか、そういったものを企業のセキュリティー室の方々が全て把握するのは、 企業規模が大きくなるほど難しいです。
そういった場合に、あらかじめ組織的にセキュリティーホールとなり得る操作を禁止しておけば、最低限のリスクは軽減できます。
また、VM（CoputeEngine）以外にも、組織ポリシーで禁止できるリソース設定は沢山あるので、コンソールで確認してみてください。
ポリシー
Google Cloudで言うポリシーとは、エンティティーにロールを割り当てたものになります。
エンティティーには、ユーザーやグループ、サービスアカウントが該当します。
AWSと比較すると、ポリシーという言葉の概念が変わってくるので、Google Cloud固有のポリシーとしての概念がある、というように覚えるのが理解しやすいかもしれません。（実際に社内の勉強会でもそうお伝えしております）
【Google CloudのIAMポリシー】
また、ポリシーを付与する際には、クラウドを利用する上で必須の考え方である最小権限の原則を遵守することがとても重要です。
最小権限の原則とは、ユーザーに対して必要最低限の権限のみを割り当てるという仕組みです。
この原則に従うことで、もしアカウントがハックされた場合でも、環境全体が乗っ取られるリスクを最小限に抑えることができます。
【最小権限の原則】
ゼロトラストのセキュリティモデルとも関連していますが、認証/認可を徹底しても、ルート権限を持つアカウントが侵害された場合、横展開されて大きな損失を被る確率が高くなります。
さらに、比較的小規模な権限であっても、ネットワーク管理や仮想マシンの操作に関する権限が悪用された場合、大きなセキュリティリスクを引き起こす可能性があります。
そのため、ポリシーの設定にあたっては、各ユーザーの役割と必要な権限を厳密に検討し、不要な権限は付与しないように心がけるべきです。
また、定期的なアクセス権限のレビューと監査を行うことで、不適切な権限が付与されていないかを確認し、必要に応じて調整を行うことがセキュリティを維持する上で重要です。
よって、Google Cloudでは、IAMプリンシパルに付与するポリシーを厳格に管理することにより、環境を守ることに繋がります。
まとめ
今回はGoogle Cloudの基礎的なリソースについて解説しました。
それぞれの組織的なリソースを区別して理解することにより、セキュリティ的な部分でリスクを回避することができます。
これからGoogle Cloudを始める方、基礎的な知識の補完をしたい方、色々な方がの参考になれば幸いです。
0
