この記事は KINTOテクノロジーズアドベントカレンダー2024 の 1 日目の記事です🎅🎄

はじめに

こんにちは、KINTO テクノロジーズ (　以下、KTC　) の SCoE グループの多田です。SCoE は「Security Center of Excellence」の略で、少し耳慣れない方もいらっしゃるかもしれません。KTC では、今年の 4 月に CCoE チームを SCoE グループとして再編しました。再編の経緯については こちらのブログ にまとめてありますので、ぜひご覧ください。また、私は大阪オフィスである Osaka Tech Lab に勤務しており、Osaka Tech Lab についても こちらのブログ でご紹介していますので、ぜひ覗いてみてください。

KTC では、多くのプロダクション環境を Amazon Web Services ( 以下、AWS ) 上で運用していますが、最近では OpenAI の活用に伴い、Microsoft Azure ( 以下、Azure ) の利用も増えてきました。

SCoE のタスクのひとつに、グループポリシーに基づくセキュリティ設定を事前に実施した上で環境を提供することがあります。本ブログでは、Azure サブスクリプションを提供する際に行っているセキュリティ設定について、いくつかご紹介したいと思います。

Azure 特有の用語が登場しますので、詳細については公式サイトなども合わせてご確認ください。

Azure ランディングゾーンと管理グループの設計

セキュリティ設定を考える上で、まずはランディングゾーンと管理グループについて理解することが重要です。KTC のサブスクリプション環境は Azure ランディングゾーンの設計原則に基づいて設計・構築しています。ただし、Microsoft の公式ランディングゾーン をそのまま使用するのではなく、ベストプラクティスを参考にしつつ、KTC の環境に合わせてライトに設計しています。

ランディングゾーン内では、サブスクリプションを論理的にまとめて効率的に管理するために、いくつかの管理グループを設計しています。以下の図はその概要です。これらの管理グループを使用し、各サブスクリプションに適切なポリシーを適用しています。

管理グループ	概要
KTC	管理グループの root、各管理グループの共通となるポリシーを適用
Management	全サブスクリプションのActivity Log の集約用のサブスクリプションなど、セキュリティ系で利用するサブスクリプションを管理
Workload	ワークロード用のサブスクリプションを管理
Sandbox	Sandbox用のサブスクリプションを管理
PolicyStaging	Azure ポリシーのテストを行うための管理グループ、サブスクリプションを管理

ポイントとして、ワークロード用の管理グループは 1 つに統一しています。この管理グループにはプロダクト用のサブスクリプションが含まれ、1 つのサブスクリプション内で 本番・開発・ステージング環境をリソースグループ単位で分離しています。

環境分離の設計には様々なアプローチがありますが、KTC ではワークロードが多くならないこと、特定の Azure サービスに限定していること、サブスクリプション単位の費用管理が容易であることから、この形でスタートしました。将来的に Azure の利用が増えれば、再検討も視野に入れています。

Management 管理グループの役割

Management 管理グループは、全サブスクリプション共通の運用管理やセキュリティツール展開用のサブスクリプションを集約するための管理グループです。運用監視を担当するメンバーのみがアクセスできるようにしており、例えば、全サブスクリプションの Activity Log を集約・監視するサブスクリプションをここで管理しています。

Azure ポリシーを利用したセキュリティ設定

Azure ポリシー を利用することで、セキュリティやガバナンスに沿ったリソースの作成が可能で、違反があれば検出・修復もできます。KTC でも Azure ポリシーを使用し、サブスクリプション作成時に自動でセキュリティ設定を適用しています。現在はビルトインのポリシーのみを使用しており、カスタムポリシーの作成までは実施していません。今後、ワークロードが増えるなど環境が変われば検討していきたいと思います。

以下は代表的な Azure ポリシーを活用した設定例です。

• Activity Log の監視と保管
• Defender for CSPM の設定と利用

Azure ポリシーは、予防的ガードレールとして、KTC では過度に適用する方針を取っていません。これは、KTC のワークロードが比較的少ないことや、エンジニアのスキルレベル、運用コスト等を考慮した結果です。厳格な予防的ガードレールで制約を増やすよりも、一定の自由度をエンジニアに委ね、発見的ガードレールで検出された内容をカイゼンするアプローチをとっています。これにより、エンジニアが問題解決を通じてスキルを磨き、興味を持って成長できるよう意図しています。

Activity Log の監視と保管

各サブスクリプションの Activity Log は、Management サブスクリプションの Log Analytics ワークスペースに集約しています。サブスクリプションが新規で追加された場合でも、Azure ポリシーによって自動的に Audit Log が集約されるよう設定しています。

利用している Azure ポリシーは以下となります。

• 指定された Log Analytics ワークスペースにストリーミングするように Azure アクティビティログを構成します

Log Analytics の保管期間はデフォルトで 90 日なので、ストレージアカウントにバックアップを保管していますが、こちらは Azure ポリシーには設定がなく、手動で行っています。カスタムポリシーを作成することで、自動設定できることは確認しているのですが、そこまでは実施していません。

Defender for CSPM の設定と利用

発見的ガードレールと呼ばれますが、Azure 環境にリスクのある設定や操作が行われた場合に、Cloud Security Posture Management ( CSPM ) のソリューションを利用して、これらのリスクを検知します。Azure の場合、 Microsoft Defender for Cloud が CSPM として利用できます。Microsoft Defender for Cloud は、CNAPPと呼ばれるクラウドネイティブアプリケーション保護プラットフォーム ( Cloud Native Application Platform ) のためのソリューションであり、CSPM や Cloud Workload Protection Platform ( CWPP ) 等をカバーするセキュリティソリューションです。

Microsoft Defender for Cloud の CSPM 機能は、無料の Foundational CSPM と サーバ、データベース、ストレージなどのリソースに対して費用が発生する Defender CSPM があります。KTC の場合、より詳細な CSPM のチェックが可能な Defender CSPM を利用しています。

Defender CSPM は、以下の Azure ポリシーを利用して、サブスクリプション発行時に自動設定しています。

• Microsoft Defender CSPM を有効にするように構成する

設定後は、定期的に Microsoft Defender for Cloud からアラート状況を監視し、リスクのある設定があれば、サブスクリプションを利用しているプロダクト側と連携し、リスクのカイゼンを行います。

クラウドワークロード保護については、今の時点では実施しておらず、今後、リソースが増えるなどに応じて検討していきたいと思います。

脅威検知

Azure 環境のセキュリティインシデントや不正アクセスを早期に発見するために、脅威検知の仕組みを導入しています。KTC でもそうですが、多くの AWS 導入会社であれば、Amazon GuardDuty で実現している仕組みだと思います。Azure の場合、 Microsoft Sentinel を使うことが鉄板のようですが、KTC の環境の場合、導入の手間や費用面を考慮し、サードパーティ製品の sysdig の CDR ( Cloud Detection Response ) 機能を使って実現しています。

CDR の実態は、OSS の Falco です。Falco は、ホスト、コンテナ、Kubernetes、クラウド環境全体に対して、異常な振る舞いや潜在的なセキュリティ脅威等の違反を検出し通知します。脅威検知ルールは、一般的なものが提供されており、カスタマイズやチューニングも可能で使い勝手がよいです。

KTC では、sysdig を Google Cloud 環境の CSPM や脅威検知として既に利用していたので、そのノウハウを Azure にも適用しています。

まとめ

KTC では、Azure サブスクリプションを提供する際に行っているセキュリティ設定について、いくつかをご紹介しました。セキュリティを強化するために、Azure ポリシー、Microsoft Defender for Cloud や sysdig の CDR 機能を活用しています。

Azure ポリシーを利用したセキュリティ設定 に記載しましたが、予防的ガードレールをどこまで厳格にするかは、各社の状況によるものが大きいと思いますので、自社の状況にあわせて最適な設計・運用をしていただくのが良いと思います。

この内容が、Azure を利用するさいの、セキュリティ設定の参考になれば幸いです。
最後まで、読んでいただきありがとうございました。

さいごに

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

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