【GCPでセキュリティの柱を築く】セキュアで統制の効いたGoogle Cloudを設計する
こんにちは、クラウドアーキテクトの山下です。
BigQuery,GKEを始めとして魅力的なマネージドサービスの多く、Next’24やRSAC24でGemini統合も進んでいるGoogle Cloud。他パブリッククラウドと比べシンプルにIaaSもPaaSも設定でき利便性も高いです。
一方、セキュリティという意味ではシンプルな設定がかえってブラックボックス的で不安という意見をお客様から良く伺います。
Google Cloudではアーキテクチャセンターという設計リファレンスドキュメントが日本語で提供されております。こちらを参考にしながら、GoogleCloudでの予防的統制、セキュアかつ統制の効いたアーキテクトについて本記事の中で考えていきたいと思います。
責任共有モデルと非機能要件5つの柱
Google Cloudでは他社のクラウドと同様に責任共有モデルが定義されています。
表現の仕方に各社で差があるものの、大まかな範囲は変わらずユーザが責任を持つべき範囲が記載されています。
GCEなどのIaaSについてはインフラ(ネットワーク,ハードウェア等)よりも上位のレイヤーすべてに対して責任を負い、GAE/GCS/BigQueryなどのPaaSはコンテンツやデータ、またそれらに対する扱いとプラットフォーム側の設定を対象としています。
また、設計のベースとなる非機能要件についても他社クラウドと同様に”柱”という形で各観点が整理されています。柱はセキュリティ、信頼性、費用の最適化、パフォーマンスの最適化、運用性となっており、AWSやAzureなどを扱っている方にも馴染み深く取り掛かりやすい項目となっています。
GoogleCloudが他社クラウドと大きくかけ離れたようなものでなく基本的な設計思想や考え方は変わりません。しかし、責任共有モデルと5つの柱以外にGoogleCloudでは柱を支える”全体設計”というベース項目が定義されています。
全てのベースとなる設計の基本原則
GoogleCloudの設計原則ではマネージドサービスの利用とシステムの自律に関わるものが特徴的です。つまり、CloudNativeな内容なのです。KubernetesやSiteReliabilityEngineering(以下SRE)などGoogle発 のサービスや運用に関わる内容に基づいているのが伺えます。以下に必要な要素を上げていきます。
①すべてを文章化する
チーム内で情報共有し、各担当者が状況把握し改善につなげるためにはドキュメントとして存在している必要があります。SREでも一人で責任を負わず状況を各担当者がコミュニケーション経路を確立し情報連携する事が重要視されています。
一度設計書を作成するだけでなく、見返して改善することでより良いものに高めていく、最適化していく材料として挙げられています。
②設計を簡素化し、フルマネージドサービスを利用する
先ほどの責任共有モデルに記載のオンプレミス,IaaS,PaaSをよりユーザが責任範囲を負わない形を求めています。既存システムの移行、新規システム構築によりスタート地点は変わりますが、マネージドサービスを活用し、ユーザが対応する箇所をなるべくGoogleCloudに寄せる事を目指しています。
[移行例]
- オンプレミスからIaaSへの移行(Lyft＆Shift)
- IaaSの拡大/最適化(モニタリング,スケーリング,運用自動化)
- IaaSからPaaSへの移行(マネージドサービス化)
- PaaSの拡大/最適化(CI/CDの導入,SREによる運用等CloudNativeなシステム構築)
③アーキテクチャを分離する
アプリケーションをモノリシックシステムからマイクロサービスまたはそれに順じた疎結合なシステムを構成する事が記載されています。そのため、ここに記載されているのはアプリケーション(Compute)に関わる内容がメインという事が分かります。
マイクロサービス化により改修や障害対策がより容易に行えるようになります。特にKubernetes,KNativeのようなCaaSまたはAppEngineのようなPaaSでのマイクロサービス実現がこれをより強固なものにします。
④ステートレスアーキテクチャを使用する
状態(≒特定のデータ)を持つものとそうでないもの、つまりステートフルとステートレスに分かれます。よくPet(ペット),Cattle(家畜)を例に挙げて説明されます。
Webサーバ,アプリケーションサーバなど状態が変化する特定のデータを持たないものを切り出し、データベースなどデータを持つものはマネージドサービスのデータベース,ストレージサービスを使う事で運用効率の最大化が図れます。
特にKubernetes上でコンテナとしてステートレスアプリケーションを展開するとその効果は絶大なものになります。コンテナ(≒Pod)が停止、再起動しても素早く代わりを展開できる耐障害性だけでなく、アップデートによる影響範囲の最小化、スケールアウトの早さなど多くのメリットを得られます。
Kubernetes Pods are mortal. Pods have a lifecycle. When a worker node dies, the Pods running on the Node are also lost.
リージョンとサービス対象を選択/導入する
他社のフレームワーク,レビューで意外と抜けているのがこの項目だったりします。
フレームワークで一通り内容を当てはめると利用しないサービスや項目も対象になっている場合があります。(例：IaCやCI/CDを導入していない,導入する段階にないのに項目にある)
データ分析を主業務に想定した環境や静的Webコンテンツを配信するようなサービスなど、ユースケースに応じて見なくていい箇所、見るべき箇所が変わります。それをまず定義、選別することで効率化を図ります。
一方、クラウドリソース,サステナビリティはどの項目でも必須になります。
[必須項目]
- クラウド リソースを管理する
- 環境のサステナビリティに関する設計
[簡易チェック項目]
- サービスのグローバル展開を想定しているのか
- アプリケーションを構成するか(コンピューティング、ネットワーク)
- 非構造データを保管するか(ストレージ)
- 構造/半構造データを利用するか(データベース)
- データ分析を行いビジネスレポートなどを作成するか(データ分析)
- 機械学習/DLを行う、または学習済みのモデル(AI)をサービスに組み込むか(機械学習)
全体のまとめ
GoogleCloudでセキュアな設計を組むならというテーマで今回は概要について触れてきました。見てきた通り、基本となる非機能要件(5つの柱)、責任共有モデルなど他パブリッククラウドと共通するものがあります。
一方で、設計のベースとなる基本原則にはGoogleが自社サービスの中で確立してきたSREの考え方やKubernetes,コンテナを基盤としたCloudNative技術が軸となっています。その中で必要なサービスの取捨選択を行い、組み込んでいく事を目指します。
次回はこの設計をより具体化していくアプローチについて触れていきます。
Discussion