Google Cloud Day ’23 Tour in TOKYOのDay3にて行われたセッション「必ずやってほしい、Google Cloud のセキュリティ対策」のレポートです。
※画像は本セッションの資料から抜粋しております。
Google Cloud Day ’23 Tourとは
Google Cloud Day ’23 Tour in TOKYOは、2023/5/23〜5/25の3日間に渡って、
Google Cloudの最新ソリューションとお客様事例についての、数多くのセッションが行われるイベントです。
オンデマンド配信もあるため、気になったセッションがあれば以下からチェックしてみましょう。
https://cloudonair.withgoogle.com/events/google-cloud-day-23
概要
登壇者
- Google Cloud 高橋 悟史 様
- カスタマー エンジニアリング セキュリティ スペシャリスト
セッション内容
Google Cloud には様々なセキュリティ機能がありますが、適切なポイントを押さえておかないとセキュリティ インシデントにつながることがあります。
本セッションでは、IAM、ネットワークなどで必ず実施してほしい対策、設定について説明します。
レポート内容
本セッションのゴール
- Google Cloudの環境で必ず確認してほしいポイントを理解し、自社環境で確認の対応を行なっていただく
- カバーしない内容
- 高度なサイバー攻撃に対する対策
- ネットワーク系のセキュリティ対策（別セッションでカバー）
クラウドセキュリティのインシデントの現状
- Google Cloud Threat Horizonレポート
- クラウド環境の脅威に関する最新情報を開設したレポートを発行している
- リソースの不正利用がされるケースについて説明されている
- このような攻撃は自動化されたツールでスキャンが行われているので、クラウド環境全てがターゲットとなる
- サービスアカウント
- サービスアカウントとは？
- Google Cloud独自の考え方で、人間が使う以外のユーザID
- アプリケーションやAPIなどを呼び出す際に使われる
- ユーザID/パスワードではなくトークンやAPIキーで認証する
- サービスアカウントに紐づく API キーをエクスポートして、Google Cloud の外部から認証させることが可能
- 攻撃者はどのようにサービスアカウントの権限を取得するのか？
- GitHubなどのパブリックリポジトリに誤ってAPIキーをポストした
- 外部からアクセス可能なVM上の脆弱性を突かれた
- デフォルトの権限
- 基本ロールの「編集者」が設定されているので、作成/削除などの幅広い権限を持っている
- 攻撃者は権限を取得して何をするのか？
- 一般的には性能の良いVMインスタンスやGPUを大量作成して、仮想通貨マイニングを行う
- 利用料金が急増するため、請求アラートなどで気づくケースが多い
- 攻撃者はバレることがわかっているので、短時間で目的を達成できてしまう
- サービスアカウントとは？
必ずやっておくべきセキュリティ対策
意識すべきこと
- ベースライン（基本的な対策）の徹底
- オンプレミスや他社クラウドのシステムと同様で、IDとアクセス制御、Firewallなどのネットワークのアクセス管理、必要な監査ログの取得と監視など
- Attack Surface （攻撃断面）の最小化
- オンプレミスのシステムの場合、OSやミドルウェアの脆弱性をついたり、VPNルーターの脆弱性を突くパターンが多い
- クラウドでマネージド・サービスを使っている場合、クラウド事業者がパッチ適用や脆弱性の修正を行うため攻撃断面が極小化される
- 攻撃者はクラウド特有の攻撃可能な方法を常に研究している
- Google Cloud に限らずクラウド上のシステムを攻撃する方法として、外部からアクセス可能なAPIキーを悪用してアクセスを得る方法が知られている
- 攻撃はほとんど自動化されている
サービスアカウントの認証情報保護に対する対策
- そもそもキーを作成しない
- どうしてもキーが必要なときは以下を気を付ける
- 公開リポジトリにポストしない
- 権限の最小化
- 侵害が置いた際にできるだけリアルタイムで気づくような監視
- 組織ポリシーのよるキー作成禁止
- 「constraints/iam.disableServiceAccountKeyCreation」をTrueにすることで無効にできる
- 既にキーが作成されているものがどれだけあるか？をコンソールから確認しておく
キーなしでサービスアカウントを使うには？
- サービスアカウントを各サービスにアタッチ
- GCE、Cloud Functions、Cloud Run、App Engineなど
- Workload Identity Federationの利用
- サービスアカウントの権限だけを権限借用することができる
- 外部からGoogle CloudのAPIを呼び出すときに、APIキーではなく一時的に有効なトークンを発行する
- キーの偶発的なポストの防止と検出
- Google Cloud Source Repositories
- サービスアカウント認証情報を含む push を検出してブロックする機能がある
- GitHub 上にシークレットやサービスアカウントキーがアップロードされていないか
- スキャンして検知する機能が Github から提供されている
- Security Command Center の異常検出機能
- サービスアカウント情報がオンラインに流出していないか検出する機能がある
- Google Cloud Source Repositories
- インスタンスメタデータの保護
- GCEやGKEはインスタンスメタデータへアクセスできてしまう
- Linux自身のファイアーウォールを設定することで、特定のユーザーしかメタデータのIPアドレスにアクセスさせない設定が可能
- 権限最小化
- デフォルトは権限が強いので、必要最小限の権限で別途作成することがおすすめ
- 監視によるセキュリティ運用
- ここまでの対策でサービスアカウントに起因する攻撃断面が極小化されるが、100%ではないのでモニタリングも重要
- Security Command Center
- ハイパーバイザー上で仮想通貨マイニングかどうかを、メモリパターンで検知する機能がある
- インスタンス側へ手を加えることをせずに使うことができる
やってもらいたいことのまとめ
- サービスアカウント利用状況の棚卸し
- サービスアカウントキーの利用をやめることが可能か検討
- デフォルトのサービスアカウントの置き換えの検討
- 仮想通貨マイニングのような事象にすぐに気付けるツールの導入の検討
QAによる補足
- 仮想通貨マイニングの検出はSecurity Command Centerのプレミア版のみ提供
- デフォルトに編集者が付いている理由としては、利便性が重視されていたという過去の背景がありそう
- キーをすでに使っている場合、ローテーションすることはおすすめしている
- Workload Identity Federationの利用にはGoogle上のコストはかからないが、IdPを外部ベンダーから出してもらう場合は料金かかるケースもある
終わりに
Google Cloud Day ’23 Tour in TOKYOのDay3にて行われたセッション「必ずやってほしい、Google Cloud のセキュリティ対策」のレポートでした。
従来のやり方として、アプリケーションにキーを組み込むような設計は多いと思いますが、可能であればサービス アカウントキーは使わないようにしたいですね。
使うとしてもこのセッションで紹介された対策は、出来得る範囲で全て実施しておいて損はないと思います。
