クラウドのセキュリティ徹底対策: サービス アカウント キーの使用を止める
Google Cloud Japan Team
※この投稿は米国時間 2024 年 2 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウドで認証情報を安全に守るという課題は、長編小説『白鯨』のようなスケールで浮上してきています。巨大な問題となって立ちはだかり、簡単な解決策はいまだ見つかっていません。また、この問題は広範囲に影響を及ぼしています。Google Cloud の 2023 年第 3 四半期版の Threat Horizons レポートによると、クラウドのセキュリティ被害のうち 69% 以上が認証情報絡みの問題（脆弱なパスワード、パスワードの未設定、公開 API など）に起因することがわかっています。しかし、小説の『白鯨』とは違い、この問題にはハッピーエンドが待ち受けているかもしれません。組織はまず、サービス アカウントを保護することで、認証情報関連の被害に遭うリスクを減らすことができます。
サービス アカウントは、クラウド管理において必要不可欠なツールです。具体的には、IAM ロールを使用して、アプリケーションに代わって API 呼び出しを行います。しかし一方で、サービス アカウントは攻撃者がクラウド環境で初期アクセスを確立するための格好のターゲットにもなっています。
「あらゆる組織のアラートの 65% 近くが、サービス アカウントの危険な使用方法に関係しています。サービス アカウントには権限が関連付けられており、攻撃者がその権限を不正利用してクラウド環境内に入り込み、権限昇格を行う可能性があります」と、Google はこのレポートで述べています。
このレポートに先んじて、2023 年第 1 四半期版の Threat Horizons レポートでも、攻撃者がサービス アカウント キーを不正利用する手口や、組織でそれを防ぐための対策について詳しく解説しました。今回のレポートでも同様の結論となっています。2023 年第 1 四半期版のレポートでは、サービス アカウントの 68% が過剰な権限のロールを与えられていることや、サービス アカウント キーが公開リポジトリにハードコードされるケースが多いこと、キーの漏洩について Google がプロジェクト オーナーに連絡した後も 42% が対策をとっていないことが報告されています。
ここでは、サービス アカウント キーの作成を全体的に防ぐ方法や、キーの使用を監視する方法、アラートに迅速に対処する方法など、リスクを軽減するヒントをご紹介します。2023 年第 1 四半期版のレポートでご紹介した方法のすべてをよくご検討いただくことを強くおすすめいたします。
サービス アカウント キーの作成を防止する
以下に示す手順は、組織のポリシーを管理するために必要な権限があることを前提としています。組織のポリシーとは、クラウド エンジニアがリソースの作成や操作を開始するのに先立って、あらかじめ設定しておく広範かつ回避不能な制限を指します。詳しくは、組織のポリシーの作成と管理をご覧ください。
サービス アカウント キーを管理するためのベスト プラクティスの一つは、組織のポリシーの制約に従って新しいサービス アカウント キーの作成を防ぎながら、他のより安全な対策を利用できないことを証明したプロジェクトに対してのみ例外的に許可するという方法です。
組織のポリシーの制約を適用する最も簡単な方法は、Google Cloud コンソールを使用することです。
この先の手順に進む前に、適切な Google アカウントにログインしていることを確認してください。組織全体に制約を適用するには、Resource Manager エクスプローラで対象の組織を以下のように選択します。
続けて、[ポリシーを管理] をクリックします。
以下のようにポリシーを適用します。
ポリシーの適用後、ユーザーがサービス アカウント キーを作成しようとすると、次のようなエラー メッセージが表示されるようになります。
組織のポリシーが変更されたケースおよびサービス アカウント キー作成されたケースを検索する
これで、サービス アカウント キーの作成を無効にできました。次は、ユーザーがこのポリシーを密かに変更し、新しいサービス アカウント キーを作成していないかどうかを確認する必要があります。
Google Cloud オペレーション スイートを使用すると、ポリシー変更の形跡を確認できます。以下の 2 つの例では、一元的な Google Cloud プロジェクトにすべてのログがまとめて保存されており、かつ、ログに対してクエリを実行する権限およびアラートを設定する権限があることを前提としています。詳しくは、以下をご覧ください。
ログ エクスプローラにアクセスします。アクション ツールバーの [範囲を絞り込む] ボタンを使用して、組織の一元的なログがある場所の範囲を選択します。
以下のクエリを使って、組織の制約「iam.disableServiceAccountKeyCreation」が変更されたケースを検索できます。
「iam.disableServiceAccountKeyCreation」に影響する組織のポリシー変更のログエントリ
このクエリに基づいてアラートを作成するには、次の、”アラートを作成して速やかに対応する” に進んでください。
サービス アカウント キーが作成されたケースを検索する
ログ エクスプローラにアクセスします。アクション ツールバーの [範囲を絞り込む] ボタンを使用して、組織の一元的なログがある場所の範囲を選択します。
以下のクエリを使用して、新しいサービス アカウント キーが作成されたケースを検索します。
新しいサービス アカウント キーが作成されたことを示すログエントリ
このログエントリは、以下のことを示しています。
- ある時点でサービス アカウント キーの作成を防ぐ組織のポリシーの制約が無効になった
- 誰かが新しいサービス アカウント キーを作成した
アラートを作成して速やかに対応する
ここまでのセクションでは、新しいサービス アカウント キーや組織のポリシー変更のケースを検索する方法を説明しました。迅速な対応を促進するには、アラートを作成して、このようなケースに速やかに対処できるようにします。
ここで説明する手順は、以下について理解していることを前提としています。
[アラートを作成] をクリックします
アラートに名前を付け、アラートに含めるログが、ログ エクスプローラでのクエリに一致することを確認します。[ログをプレビュー] をクリックし、エントリが正しいことを確認します。通知頻度と自動クローズ期間を設定します。
通知チャンネルを選択します。通知チャンネルを作成する必要がある場合は、こちらの手順に沿って操作してください。
以下に、筆者がサービス アカウント キーを作成したことによってトリガーされたインシデントを示すメールアラートの例を示します。
[インシデントを表示] をクリックすると、アラートのページが開きます。
インシデントをクリックすると、以下の情報が表示されます。
- 条件
- ログのクエリ
- クエリに一致するログのセット
- インシデントがトリガーされた日時
インシデントの詳細
次のステップ: 共同インシデント管理プロセスを構築する
ここでは、サービス アカウント キーの使用に伴うリスクについて確認したうえで、サービス アカウント キーの作成を全体的に制限する組織ポリシーを適用し、ポリシー違反を継続的に監視する方法を説明しました。これにより、クラウド環境内に潜む最大のリスクに的確に対処できることがおわかりいただけたと思います。
共同インシデント管理プロセスを構築するもぜひお読みください。ここで説明したインシデントやその他のインシデントへの対応を運用化する方法を説明しています。ここで巨大な白鯨を追跡する、という壮大なドラマを求めている人はいないでしょう。サービス アカウント キーの使用を止めることこそが、クラウド セキュリティを高めるためのはるかに簡単な方法なのです。
ー デベロッパーリレーションズ エンジニア Luis Urena
