はじめに

こんにちは、KINTO テクノロジーズ ( 以下、KTC ) SCoE グループの桑原 @Osaka Tech Lab です。

SCoE は、Security Center of Excellence の略語で、まだ馴染みのない言葉かもしれません。KTC では、2024 年 4 月に CCoE チームを SCoE グループとして再編しました。SCoE グループについて知りたい方は、クラウドセキュリティの進化をリードする SCoE グループ を参照ください。

また、KTC の関西拠点である Osaka Tech Lab については、Osaka Tech Lab 紹介 をご参照ください。

SCoE グループでは、AWS や Google Cloud , Azure のクラウドにおける「ガードレール監視と改善活動をリアルタイムで実施する」をミッションに活動しています。具体的な活動の観点としては以下の 3 つです。

• セキュリティリスクを発生させない
• セキュリティリスクを常に監視・分析する
• セキュリティリスクが発生したときに速やかに対応する

今回は「KTC のクラウドセキュリティエンジニアって何をやってるの？」を具体的に知っていただこうと思います。

クラウドセキュリティエンジニアのとある一日

具体的なイメージをしていただくために、クラウドセキュリティエンジニアの "とある一日" をご紹介します。（セキュリティという分野の都合上、詳細に語れない部分があることをご了解ください。）

アラート確認

朝一番に行うのは、リスクの高いアラートが発生していないかの確認です。CSPM（Cloud Security Posture Management）や脅威検知サービスを使用して、クラウド環境全体のセキュリティ状況を把握し、即時対応が必要なアラートがないか確認します。
KTC では、CSPM や脅威検知サービスとして、AWS Security Hub や Amazon GuardDuty、 Sysdig Secure 等のサービスを活用しています。

アラートを確認する際は、以下の観点で対応します。

• アラートの優先順位付け: 重大度や影響範囲に基づいてアラートを分類し、優先順位を付けます。
• アラートのトリアージ: 発生したアラートの原因を特定し、必要な対応策を講じます。
• 偽陽性（過検知）の管理: セキュリティツールは時折、偽陽性（False Positives）を発生させることがあります。これにより、実際には問題のないアクティビティがアラートとして報告されることがあります。これらの管理もアラート処理として対応します。
• 業務上必要なオペレーションの識別: 偽陽性の管理に関係しますが、一部のアラートは、業務上必要なオペレーションによって引き起こされることがあります。例えば、各プロダクトの担当者が定期的に行うメンテナンス作業などです。これらのアクティビティを識別し、適切に対応します。

これにより、クラウド環境全体のセキュリティ状況を把握し、即時対応が必要なアラートがないか確認します。

情報収集、キャッチアップ

次に、サイバーセキュリティの動向や AWS などのクラウドサービスの最新情報をキャッチアップします。情報源としては以下のものを利用します。

• X（旧:Twitter）: サイバーセキュリティの専門家や業界リーダーをフォローしています。彼らは最新の脅威情報や対策を共有しているため、リアルタイムでの情報収集が可能です。
• AWS や Google Cloud の公式ニュースやブログ: クラウドサービスプロバイダーの公式情報は、新機能のリリースやセキュリティアップデートに関する重要な情報源です。これにより、新サービスのローンチ情報や最新の技術動向、ベストプラクティスを把握できます。
• その他ニュースサイト: サイバーセキュリティに特化したニュースサイトやブログを定期的にチェックすることで、業界全体の動向を把握し、最新の脅威や攻撃手法についてキャッチアップします。

SIEMでの脅威検知

KTC では、SIEM（Security Information and Event Management）として、Splunk Cloud Platform を使用しています。この Splunk にセキュリティ関連ログを集約し、ログの横断分析と監視を行える環境を整備しています。

この日は、Splunk のダッシュボードにて、違和感のあるログを発見しました。内容としては、「Google Cloud の組織ポリシーで制限されているサービスに対して、リソース作成を何度しようとしてオペレーションに失敗している」というものです。

Splunk にて独自に作成している　Google Cloud Audit logs 用のダッシュボードの情報から、おおよそのアクティビティは判断できていましたが、より詳細に調査します。

まず、Google Cloud の組織ポリシーで制限をかけているサービスに対して、リソース作成を何度もリトライしているユーザーを特定します。
Google Cloud の Audit log (audit:policy_denied) ではユーザー情報はマスクされた状態でログ出力されるため、このログ単体ではユーザーは特定できません。端末系のログなどと一緒に横断的なログを分析することで、ユーザーを特定します。この分析に使用するクエリを作成し、該当のユーザーを特定しました。

次に特定したユーザーの行動を詳細に分析するためのクエリを作成し、ログを分析します。

どうやら、AI/ML のサービスである Vertex AI を使用しようとしている模様です。該当のプロジェクトでは、Compute 系の利用申請は出ていませんでしたので、組織ポリシーにて Compute 系サービスの使用を制限をしています。
Vertex AI は、Notebook を使用する際に、Compute Engine (GCE) インスタンスが起動します。よって、この部分で組織ポリシー違反となります。

結果的に、「Google Cloud プロジェクト新規発行申請時に利用予定サービスの記載漏れがあった」ということで、この件は、問題ないアクティビティであることを確認しました。

クラウドベンダーネイティブのセキュリティサービスに対するコスト最適化検討

クラウドベンダーが提供するセキュリティサービスは従量課金制であり、クラウドリソースが増加すると、それに伴ってセキュリティサービスの利用料も増加します。

私たちが考える「セキュリティ」は、「ビジネスのためのセキュリティ」であり、「ビジネスを阻害するセキュリティ」は NG です。
そのため、「セキュリティとコストのバランス」も重要なポイントであり、セキュリティサービスのコスト最適化も SCoE グループのミッションに含まれます。

この日は、全体コストの中で割合が高いいくつかのセキュリティサービスについて、コスト最適化の可能性を調査しました。

上記のグラフは、今回の分析対象となったサービスを示しています。その中でも特に AWS Config に注目しました。（具体的な項目名はマスキングしています）

AWS Config は、AWS リソースの構成を監査、評価、そして記録するためのサービスです。2023 年 11 月までは、AWS Config の記録方式として「リソース構成の変更が発生するたびに記録する方式」しか提供されていませんでした。この方式は、「記録頻度：継続的な記録」と呼ばれています。
つまり、リソースの変更頻度が高い場合、AWS Config の記録回数が増加し、それに比例して利用料金も増加する仕組みです。

例として、ネットワーク関連のイベントを確認してみましょう。以下のデータは、ある AWS アカウントにおける 1 週間分の VPC およびネットワーク関連の構成変更回数を示したグラフです。

Elastic Network Interface (ENI) の作成・削除に該当する　CreateNetworkInterface と DeleteNetworkInterface が一日あたり約 17,000 件発生していることがわかります。
KTC では、Amazon Elastic Container Service (ECS) の Fargate を活用しています。このため、ECS タスク (コンテナ) が起動・停止するたびに、ENI の作成・削除が発生します。このような状況下で AWS Config を「記録頻度：継続的な記録」に設定している場合、これらの変更に伴う AWS Config の記録回数が膨大になり、それに応じて課金額も増加します。

しかし、2023 年 11 月以降、AWS Config に「記録頻度：日次記録」を選択できる機能が追加されました。この新機能により、リソースタイプごとに記録頻度を調整することが可能となり、セキュリティとコストのバランスを柔軟に取ることができるようになりました。一般的には、この設定を活用することで AWS Config の利用コストを最適化できると考えられています。

ただし、これは AWS Control Tower を使用していない場合に限ります。AWS Control Tower は複数の AWS アカウントのガバナンスを一元管理するためのサービスです。

AWS Control Tower を利用して AWS アカウントの AWS Config を管理している場合は、 Guidance for creating and modifying AWS Control Tower resources を確認してください。

ガイダンスの冒頭に記載されている以下の一文に注目してください。

Do not modify or delete any resources created by AWS Control Tower, including resources in the management account, in the shared accounts, and in member accounts. If you modify these resources, you may be required to update your landing zone or re-register an OU, and modification can result in inaccurate compliance reporting.

この記載が示すように、AWS Control Tower によって作成されたリソースを AWS Control Tower 以外の方法で変更または削除することは非推奨です。

具体的には、2024 年 12 月現在、AWS Control Tower では AWS Config の記録頻度を変更する機能が提供されていません。そのため、AWS Control Tower 管理下の AWS Config の記録頻度を変更することは非推奨とされており、公式ドキュメントにも問題が発生する可能性があると記されています。

公式ドキュメントの内容を踏まえつつ、念のため AWS サポートにも問い合わせを行ったところ、同様の見解を得ました。

このように、「設定そのものは可能であっても、問題が発生するリスクがある、または非推奨とされる」場合には、安定したクラウドセキュリティとガバナンスを維持することが難しくなります。その結果、「ビジネスを阻害するセキュリティ」 となりかねません。

以上を踏まえ、AWS Config の記録頻度変更は現時点では見送ることとし、AWS サポートに改善要望を提出しました。クラウドサービスの利便性向上を目的としたこうした改善要望の起案は、地道ではありますが非常に重要な取り組みであると考えています。

セキュリティ勉強会の準備

最後に、定期的に実施している社内セキュリティ勉強会（セキュリティ＆プライバシー勉強会）での登壇資料を作成しました。

SCoE グループでは、プロダクト開発時の「要件定義」「設計」「開発」フェーズにおけるクラウドセキュリティの勘所をまとめた、"クラウドセキュリティガイドライン" を策定し、社内向けに公開しています。
このガイドラインは、KTC が所属するグループ企業のセキュリティポリシーを遵守し、セキュリティリスクを最小限に抑えつつ、効率的な開発を支援するための重要なリソースです。

この "クラウドセキュリティガイドライン" の周知と理解を促進するために、勉強会でのセッションを受け持っています。勉強会では、具体的な事例や実践的なアドバイスを交えながら、ガイドラインの各項目について詳しく説明します。

この日は、IAM（Identity and Access Management）のベストプラクティスについて、持ち時間 20 分に収まるサイズの登壇資料を作成しました。

さいごに

KTC のクラウドセキュリティエンジニアのとある一日をご紹介いたしました。業務のごく一部でしたが、業務内容をイメージできましたでしょうか？

我々 SCoE グループでは、一緒に働いてくれる仲間を募集しています。クラウドセキュリティの実務経験がある方も、経験はないけれど興味がある方も大歓迎です。お気軽にお問い合わせください。

詳しくは、こちらをご確認ください。