toittaチームSREの
id:cohalzです。
この記事は、はてなのSREが毎月交代で書いているSRE連載の9月号です。8月の記事は
id:walnuts1018さんのはてなブログや GigaViewer で使われている画像変換プロキシを EC2 から EKS に移行しましたでした。
はてなでは2024年7月に生成AIを活用したtoittaというサービスをベータ版でリリースしました。現在正式リリースに向けて準備中で、無料トライアルも実施中です。
このサービスはビジネス向けのSaaSアプリケーションで、インフラはGoogle Cloud上に構築しています。
ユーザーの皆様に安心してサービスをお使いいただくために、どうやってセキュアなサービスにしていったのかを、toittaで利用しているGoogle Cloudのセキュリティ系のサービスと合わせて紹介していきます。
Security Command Centerについて
toittaではセキュリティ全般の確認、対応のためにSecurity Command Centerのプレミアムティアを利用しています。
プレミアムティアは以前は最低金額($15,000/年)が存在していましたが2023/06に改定され、使用しているリソースに応じた従量課金になり非常に利用しやすい価格感になりました。
料金は利用しているCompute EngineやCloud Storageなど主要なサービスの使用量のみで決まるため事前に費用の見積もりもしやすいです。
費用感についてもう少し見ると、Cloud SQLでは $0.0071 / vCPU(時間) となっています。Cloud SQL自体の費用は $0.054 / vCPU + $0.0092 / メモリGB(時間) であり、専用コアインスタンスの最小構成の場合では約8%の費用増となりそこまで高くない価格になっているのがわかるかと思います。
Security Command Centerの中でも様々なサービスがありますが、その中でtoittaで利用しているサービスに関して紹介していきます。
Security Health Analytics
Google Cloud上の脆弱な設定(ファイアウォールのポート公開やGCS全公開など)をチェックして教えてくれるサービスです。
こちらのサービスはスタンダードティアでも利用できますが、プレミアムティアのみチェックしてくれる項目も多いため、これ目当ての場合だけでもプレミアムティアに変更したほうが良いかなと思います。
どの項目がどのティアで使えるかは下記ドキュメントの「Security Health Analytics の検出結果」から確認することができます。
また、プレミアムティア以上の機能として個人的に好きなものとして、各コンプライアンス標準に準拠しているか確認できるようになることです。
このページを基に準拠したいコンプライアンス標準に適合しているか確認し、準拠していない項目は何かすぐ確認できるようになっています。
Event Threat Detection
監査ログからAPIの無効化やDBのバックアップ削除など不審なアクティビティがあった際に通知してくれるサービスです。
既存のルールで不要なものがあれば無効にできるほか、追加でCompute Engineに関するルールや不審な接続元・接続先のチェックなども自作することができます。
チェックするにはアクティビティ監査ログを有効にする必要がありますが、既に有効にしている場合はほぼ何もせず追加費用もSecurity Command Centerだけで導入することができます。
Virtual Machine Threat Detection
Compute Engine上でマルウェアやマイニングが実行されているかどうか検出するサービスです。スキャンはインスタンス作成時および定期的(種類によって頻度は異なる)に実行されます。
このサービスは特に追加で設定する必要はなくすぐに使い始めることができます。
その他のサービス
Security Command Centerにはそのほかに脆弱性診断を行うWeb Security Scannerやコンテナ周りのセキュリティチェックを行うContainer Threat Detectionがありますがtoittaでは用途に合わず利用しなかったため今回は紹介を省きます。
リアルタイム通知について
これらのサービスの検出項目はコンソール上で確認できるほか、Pub/Sub経由でCloud Run関数(旧Cloud Functions)を実行させることができるため、Event Threat Detectionで検出されたセキュリティ侵害など不審なアクティビティをSlackに即時通知する仕組みを実装して状況を確認しています。
サプライチェーン攻撃対策について
次に、toittaで実践しているサプライチェーン攻撃対策について紹介します。
実践しているものとして使用しているライブラリやOSの脆弱性スキャン、改ざん防止のためのコンテナイメージの来歴の検証などがあります。
toittaではCloud RunやCloud Batchを用いてコンテナイメージを動かしています。 そのビルドはCloud Buildで、イメージの保存にはArtifact Registryを利用しています。
そのコンテナイメージがちゃんと特定のリポジトリからトリガーされCloud Buildでビルドされたものであるかどうかを確認するように構築する方法を紹介していきます。
まず、Cloud BuildではSLSAフレームワークに則った改ざん防止のプロセスを簡単に利用することができ、Cloud Runではこれを利用しています。
利用するためにはまずContainer Analysis API(containeranalysis.googleapis.com)を有効にし、Cloud Buildのサービスアカウントにserviceusage.services.useの権限を追加することが必要です。
その後はCloud Build上で requestedVerifyOption オプションを追加することでビルドの来歴を作成することができます。
options: requestedVerifyOption: VERIFIED
来歴を作成するとCloud Buildのコンソール上からもSLSAビルドレベル3である証を確認できるようになります。
このイメージをCloud Runにデプロイすると、Cloud Run上のコンソールなどでもイメージの来歴を確認することができ、今動いているCloud Runのリビジョンが改ざんされてないことを確認することができるようになります。
さらにBinary Authorizationというサービスを利用することで、Cloud Runのデプロイ時にこの来歴を出力したCloud Buildでビルドされたイメージ以外のデプロイを拒否するといったルールもシステム化することができます。
Binary Authorizationで built-by-cloud-build という認証者が自動で作成され、これを利用することで簡単に組み込むことが可能です。
組織でこのポリシーを一括で強制するということも可能になってます。
脆弱性のスキャンに関してはContainer Scanning API(containerscanning.googleapis.com)を有効にすることでコンテナイメージに含まれる脆弱性を自動で診断し、同じ画面でも確認できるようになります。
また、gcloud artifacts sbom exportというコマンドをコンテナイメージを指定して実行することでGCSにSBOMファイルを出力することもできるようになります。
- name: gcr.io/cloud-builders/gcloud args: - 'artifacts' - 'sbom' - 'export' - '--uri=asia-northeast1-docker.pkg.dev/$PROJECT_ID/$IMAGE/$COMMIT_SHA'
こちらも同様に同じ画面で確認できるようになり、このファイルをダウンロードしてOSV-Scannerなどのツールで中身を確認できるようになります。
Cloud Run以外で改ざんされているかどうかチェックしたい場合には、slsa-verifierというツールを使うことでそのコンテナイメージがCloud Buildでビルドされ、そのソースリポジトリが想定しているものかどうか確認することができます。
slsa-verifierを用いた改ざんチェックの流れは以下のようになります。
- ハッシュ形式(
@sha256:xxx) でイメージを利用するようにする gcloud artifacts docker images describe $IMAGE_URI --format json --show-provenance > $PROVENANCE_FILEで来歴情報を取得するslsa-verifier verify-image $IMAGE_URI --source-uri $GITHUB_URI --provenance-path=$PROVENANCE_FILE --builder-id=https://cloudbuild.googleapis.com/GoogleHostedWorkerで取得した来歴を検証する
これを実行したいコマンドの前に差し込むことで、もし実行したいイメージがCloud Buildでビルドされていなかったり、リポジトリのURLが違った場合には失敗させることができます。
toittaではこの処理をCloud Batchで本来の処理の直前で実行し、来歴が検証されていないイメージだった場合に後続の処理を実行できないようにしてセキュリティ侵害を防ぐようにしています。
その他のセキュリティ対策について
最後に、Google Cloud以外のセキュリティ対策についても軽く紹介していきます。
データベースに関してはCloud SQL上でPostgreSQLを用い、Row Level Security(RLS)でマルチテナント環境を実現しています。こちらに関してはまた別の機会に紹介できればと思っています。
脆弱性診断もベータリリースのタイミングで実施しました。株式会社Flatt Securityの脆弱性診断を利用し、Google Cloudのセキュリティに関してShisho Cloudを用いて診断してもらいました。 Shisho Cloud上の結果とSecurity Command CenterのSecurity Health Analyticsのダブルチェックを行い、優先度の高い項目から対応していくようにしています。
脆弱性診断の際にソースコード診断も一緒に実施してもらいましたが、深刻度は低いものの発見が難しい正規表現のミスなども指摘してもらうなど非常に良い体験でした。
まとめ
セキュリティ関連の機能やSaaSを利用して要件を満たすということは費用や手間の掛かるイメージがどうしてもありましたが、現代ではGoogle Cloud公式の機能など非常に安く手間もかからずに導入できることがわかりました。
Google Cloudでサービスを作成するというのは社内でもあまりなかったですが、今後こういった機能をデフォルトで有効にし組織で強制しても良いかなと思いました。
