KINTO Tech Blog

CCoE

CCoE活動とGoogle Cloudセキュリティプリセット環境の提供

Tomoaki Tada
Tomoaki Tada
Cover Image for CCoE活動とGoogle Cloudセキュリティプリセット環境の提供

こんにちは、KINTOテクノロジーズ プラットフォームグループ CCoE(Cloud Center of Excellence)チームの多田です。

CCoEチームは、「クラウドサービスを利用したシステム開発の積極的な推進とガバナンスによる統制を通じて、モビリティプロダクトの開発を、よりアジャイルかつセキュアにする」ことをミッションに活動しています。

KINTOテクノロジーズにおけるCCoE

CCoEの活動内容

CCoEチームは、上述のミッションの元、クラウドの「活用」と「統制」を幅広く支援する組織として、多くの施策に取組んでいます。代表的なものをいくつかご紹介しておきます。

クラウドの「活用」

ナレッジ共有や人材育成を通じて、効率的な開発が継続的に支援を行うをあるべき姿とし、次のことに取組んでいます。

  • クラウド人材育成
    • KINTOテクノロジーズ独自のAWSスキルマップを利用した勉強会や教育コンテンツを整備し、エンジニアスキルをレベルアップする

クラウドの「統制」

グループ会社セキュリティポリシーに準拠したクラウド環境を提供し、常にセキュアな状態を維持するための支援を行うをあるべき姿として、次のことに取組んでいます。

  • クラウドセキュリティガイドライン
    • セキュリティポリシー準拠のためのIaC開発とセキュリティツールを整備する
  • セキュリティプリセットクラウド環境
    • 上記セキュリティガイドラインに則った設定済みのクラウド環境を提供する

我々の活動内容を簡単な絵にすると次のような形になります。
クラウドセキュリティガイドラインを中心として、その内容を事前設定したクラウド環境を提供し、開発グループに利活用してもらう。このクラウド環境をセキュアに維持するために、SIEM(Security Information and Event Management)やCSPM(Cloud Security Posture Management)でモニタリングを行っています。また、セキュリティガイドラインを人材育成や情報共有サイト等にも利活用する。といった活動を行っています。
セキュリティについては、日々情報がアップデートされますし、クラウドサービスも常に進化していきます。そのため、それらに追随するために、ガイドラインを中心とした持続的な活動を目指しています。


ここからは、現在、クラウドの「統制」で進めている、「セキュリティプリセットクラウド環境(Google Cloud)」について紹介していきます。

セキュリティプリセットクラウド環境(Google Cloud)の取組み

セキュリティプリセットクラウド環境(Google Cloud)とは

セキュリティプリセットクラウド環境は、アジリティとセキュリティの両輪を実現し、アジャイルな開発を促進することを目的として開発しています。

  • 開発グループがクラウド環境を自由に利活用できる
  • 企業として、最低限望ましくない利用を制限

では、具体的にどのようなセキュリティを設定しているか、ということですが、ベースとなるセキュリティ基準は以下の2つとなります。

  1. CIS Benchmark
  2. グループ会社のセキュリティルール

さらに、これらをどこに設定しているのか、ということですが、こちらは、以下の3箇所で設定しています。

  1. 組織ポリシー
  2. プロジェクト(作成時に設定)
  3. CSPM(Cloud Security Posture Management)

以降で、それぞれの箇所にどうようなセキュリティ設定を実装しているか具体的に説明していきます。


組織ポリシーで設定したセキュリティは何か

組織ポリシーは、最低限望ましくない操作を制限するために利用します。これは、予防的ガードレールと呼ばれる考えかたと同様です。
予防的ガードレールは、システムやプロセスにおいて、予防的な制約や制限を設けることで、望ましくない行動やリスクを事前に防止する仕組みやルールの総称で、人為的なミスや意図しない行動によるセキュリティ上の問題やコンプライアンス違反を最小限に抑えることができます。
セキュリティプリセットクラウド環境では、あまり厳しい制限にならないように、本当に最低限実施してほしくない操作に絞って制限するようにしています。最低限の基準として、上述の2つのセキュリティ基準をベースにしています。実際に設定しているいくつかの、組織ポリシーを紹介します。

組織ポリシー 説明
constraints/gcp.resourceLocations リソースを作成できるロケーションを制限。asiaなどのマルチリージョンを設定
constraints/sql.restrictPublicIp Cloud SQLインスタンスへのパブリックアクセスを制限
constraints/storage.publicAccessPrevention Cloud Storageのデータのパブリック公開を制限
constraints/compute.skipDefaultNetworkCreation リソースの作成時にデフォルトネットワークと関連リソースの作成を制限
constraints/iam.disableAuditLoggingExemption 監査ログからプリンシパル除外設定を制限

これらの組織ポリシーを組織全体に設定し、フォルダ配下やプロジェクトにも同様のポリシーを継承しています。万一、プロジェクト側で、これらのポリシーが許容できない場合は、プロジェクト固有でポリシーをオーバーライドする運用となっています。

プロジェクト作成時に設定したセキュリティは何か

組織ポリシーで設定できないが、予防的ガードレールとして設定したいルールについては、プロジェクト作成時に設定しています。
例えば、CIS Benchmarkには、「2. Logging and Monitoring」「2.13 Ensure Cloud Asset Inventory Is Enabled」というルールがあり、Cloud Asset Inventoryの有効化をプロジェクト作成時に自動化して実施しています。
その他、プロジェクト作成時に設定しているCIS Benchmarkのルールを紹介します。

項目 タイトル 説明
2.4 Ensure Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes プロジェクトオーナーの割当を監視しアラートを通知する
2.5 Ensure That the Log Metric Filter and Alerts Exist for Audit Configuration Changes 監査設定の変更を監視しアラート通知する
2.6 Ensure That the Log Metric Filter and Alerts Exist for Custom Role Changes プロジェクトオーナー、組織ロール管理者、IAMロール管理者はカスタムロールを作成できる。カスタムロールの作成は過剰な特権を持つ可能性があるため監視しアラート通知する
2.7 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes ファイアウォールルールの作成または更新を監視しアラート通知する
2.8 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Route Changes VPCネットワークのルート変更を監視しアラート通知する
2.9 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Changes VPCネットワークの変更を監視しアラート通知する
2.10 Ensure That the Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes Cloud StorageのIAM権限変更を監視しアラート通知する
2.11 Ensure That the Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes SQLインスタンスの設定変更を監視しアラート通知する

また、プロジェクト作成時ではないですが、以下のCIS Benchmarkのルールを組織全体に設定としています。

項目 タイトル 説明
2.1 Ensure That Cloud Audit Logging Is Configured Properly すべてのアクティビティ、ユーザデータへの読み取り、書き込みアクセスを追跡するために監査ログを設定する


CSPMで設定したセキュリティは何か

CSPM(Cloud Security Posture Management)で実現したセキュリティを説明します。CSPMでは組織ポリシーでも、プロジェクト作成時にも設定できない、リスクのある操作についての検知・通知を実現するために利用しています。
これは、発見的ガードレールという考え方に一致します。
発見的ガードレールは、システムやプロセスにおいて異常な活動やセキュリティ上のリスクを検出し、早期に発見するための仕組みやルールであり、インシデントや異常な活動の発見・分析に重点を置きます。予防的ガードレールと発見的ガードレールは相補的な役割を果たすものです。
セキュリティプリセットクラウド環境では、発見的ガードレールの考え方のもと、CSPM製品を使ったリスクの検知・通知を実現しているのですが、CSPM製品の選定に少し紆余曲折がありました。

採用したCSPM製品は何か

CSPM(Cloud Security Posture Management)は、クラウド環境における、クラウドリソースのセキュリティ設定や構成を監視し、ベストプラクティスに基づいたポリシーやガイドラインに準拠しているかどうかを評価・管理するためのツールです。
Google Cloudでは、Security Command Centerと呼ばれるサービスがあり、StandardとPremiumの2つのティアが存在します。

Standard Premium
Security Health Analytics
(重大な構成ミスの特定を含む)
Security Health Analytics
(PCI,CIS,コンプライアンスレポート等)
X
Web Security Scanner X
Event Threat Detection X
Container Threat Detection X
Virtual Machine Threat Detection X
Rapid Vulnerability Detection X
費用 無料 サブスクリプション

我々としては、CIS Benchmark等を基準に「発見的ガードレール」を実現したいと考えていたため、要件的には、Premiumの利用となるのですが、費用的には高価で、現在のGoogle Cloudの利用規模でいうと割にあいません。
では、CSPM製品をどうしたかというと、以下の観点でいくつの製品をピックアップし、机上調査とPoCを実施しました。

  • CIS Benchmark等のコンプライアンス基準が利用できる
  • 独自ルールも実装できる
  • 安価である(Security Command Center Premiumの費用と比べて)

主な製品と評価コメントは次のとおりです。

  • Forseti Security(Open-source security tools for GCP)
    • Google Cloudリソースのインベントリ情報を収集して、定期的に監査ルールをチェックする。監査ルールは、「IAMポリシー」、「バケットACL」、「BigQueryデータセットのACL」、「Cloud SQLネットワーク」等であり、CIS等のコンプライアンス基準が利用できない
  • Cloud Custodian(OSS)
    • CIS等のコンプライアンス基準のデフォルトルールセットがないため、各ルールを0から実装する必要がある
  • サードパーティ製品(S社)
    • CIS等のコンプライアンス基準がデフォルトで準備されており、独自ルールもRegoで実装することができる。SaaS製品であるが価格も非常に安価でマーケットプレイスから購入もできる

これらの調査結果をもとに、サードパーティ製品(S社)を採用することに決めました。Cloud Custodianと迷いましたが、製品のインテグレーションやルール実装のスピード感を優先し決定しています。この製品を具体的にどのように利用しているかは、また別の機会にブログにしようと思いますが、CSPM製品を導入し、CIS Benchmark等を基準にリスクのある操作を検知・通知し、改善を行うことでセキュアな状態を維持することに努めています。

プロジェクトのIAM権限はどうしているか

もう一つ重要なことがあります。それは、開発グループに払い出すプロジェクトのIAM権限をどうするかという問題です。結論からいうと、利用者には「編集者」権限を付与しています。
もちろん、「編集者」権限を付与することは、バッドプラクティスであることは理解しているのですが、開発グループ側の利便性とセキュリティをトレードオフし、まずは、この権限でスタートしています。その代わり、Policy Intelligenceツールの運用を徹底し、最小権限の原則に近づけるような運用をしていくこととしています。このあたりも別の機会にブログにしたいと思います。

まとめ

セキュリティプリセットクラウド環境についてまとめると、以下となります。

  • 開発グループが自由に利活用でき、かつ、最低限の望ましくない操作が制限されているクラウド環境を実現
  • 実現には、「予防的ガードレール」と「発見的ガードレール」の考え方を採用
  • 予防的ガードレールは組織ポリシー、発見的ガードレールは、CSPM製品を利用することで実現
  • IAM権限は、最小権限の原則に近づける運用をPolicy Intelligenceツールで徹底

今後のCCoE活動

最後に今後のCCoE活動についてふれておきます。
今回は、Google Cloudのセキュリティプリセット環境を紹介しましたが、AWSについても同様のコンセプトでセキュリティプリセット環境を準備しています。さらにセキュリティプリセット環境をセキュアに維持するため、セキュリティのモニタリングサービス/ツールを充実させようと考えています。今回は、CSPMについて少し紹介しましたが、CSPM以外のCNAPP(Cloud Native Applicaiton Protection Platform)とよばれる領域のツールについても整備を進めようとしています。また、最近、少しずつ耳にするようになった、X.1060フレームワークを使って、セキュリティ対応組織力の継続的な向上にも着手していく予定です。機会があれば、この辺りも紹介できればと思います。
ここまで読んでいいただきありがとうございました。

KINTOテクノロジーズMeetUp!情シスによる情シスのための事例シェア

関連記事 | Related Posts

We are hiring!

【CCoE】プラットフォームG/東京・大阪

プラットフォームグループについてAWS を中心とするインフラ設計、構築、運用などを担当しています。

【プラットフォームエンジニア】プラットフォームG/東京・大阪

プラットフォームグループについてAWS を中心とするインフラ設計、構築、運用などを担当しています。