【AWS re:Invent 2024】大規模システムのセキュリティオブザーバビリティのためにできること [SEC316]

こんにちは、MSPの田所です。

AWS re:Invent 2024 が盛り上がっていますね！
現場からイベント模様をお届けします。

セッション情報

Elevating your data security posture through scalable observability

大規模になってもセキュリティのオブザーバビリティは守りましょう！

As organizations mature in their cloud journeys—from a single application in an account to having multiple accounts across multiple Regions—understanding data security at scale helps them architect their environments. Delve into the art of balancing data security, observability, and cost as you scale with AWS data protection services. Gain insights into best practices for safeguarding data, implementing least privilege, monitoring, and decentralized management to enable developer agility while satisfying security and compliance controls. For seasoned cloud architects and security professionals, gain the knowledge and tools to optimize your approach to data protection in AWS.

大規模システムのセキュリティオブザーバビリティの大切さと、実装のポイントについて語ります！

Session types: Chalk talk

1時間のチョークトーク

今回のまとめ

• セキュリティでもオブザーバビリティは大事
• システムの規模によって設定や管理方法は変わる
• セキュリティオブザーバビリティのベストプラクティス

セッションの詳細

1. セキュリティオブザーバビリティ

まず技術進歩に伴って、システムを把握するために求められることが変化してきているという話から始まりました。

以前はイベントやトランザクションのログを後追いするのみでしたが、
メトリクスを定めて継続的に監視することでリソース状況を把握できるようになります。
さらに、パフォーマンスやサービスの関係性を可視化することでシステムの状態把握ができるようになりました。
そして現在は、上述のロギング、監視、可視化を組み合わせて洞察を得ることで、システムに対してプロアクティブに問題解決や最適化を行う技術が整ってきました。

これがクラウドにおけるオブザーバビリティで、今後システム把握のために求められることです。

オブザーバビリティというと、私はインフラの稼働状況やアプリのパフォーマンスのことを想像したのですが、実はそれだけではありません。
注目する要素として以下が挙げられていました。

• セキュリティ：アカウントやワークロードが保護されているか
• パフォーマンス：リソース使用状況が最適か
• データ損失：データ保護のコンプライアンスを遵守しているか
• ダウンタイム：サービスが障害なく稼働しているか
• 利用制限：リソースの利用上限が適切に設定されているか

そしてデータのセキュリティの観点では、見るべき要素として以下の3つがあります。

• IAM：ロールやポリシーの設定状況
  • 新機能として発表された Resource Control Policies (RCPs) も紹介がありました
• リソース：S3 バケットポリシーなどリソースベースのポリシーの設定状況
• セキュリティリソース：KMS キー、Secrets Manager シークレット、証明書など

このあたりのオブザーバビリティと聞くと少し新鮮でした。

2. 大規模になると変わること

小規模なシステムであれば、特に管理に悩むことはないかもしれません。
単独のアプリ、いくつかのロールやキー、数えられる程度のシークレットであれば、コンソールですぐに確認を終えられそうです。

それが中規模になってくると難しさが出始めます。
10以上ののアプリやロール、多数のシークレットがある場合には、管理ツールや管理プロセスが必要になるかもしれません。

そして大規模になると人力では手に負えません。
100以上のアプリやキー、1,000を超えるシークレットがあると、設定や管理の自動化並びにオブザーバビリティ（状況把握およびプロアクティブな修正ができること）が必要になってきます。

規模によって管理の手間や手法が大きく変わってくるということですね。

3. ベストプラクティス

大規模なシステムのセキュリティオブザーバビリティにおいて、以下のベストプラクティスが紹介されていました。

• セキュリティリソースの可視化を一元化する
• 異常検知を行う
• 最小権限を維持する
• 使用していないリソースを削除する

 

① セキュリティリソースの可視化を一元化する

まず一元化からです。
管理の一元化というと、例えば KSM キーや Secrets Manager シークレットをひとつのセキュリティアカウントに集約した上で、必要なそれぞれのアカウントで使用することも一元化と言えそうです。
ただしこのケースは、アカウントを跨いだ権限管理が非常に煩雑になり、ベストとは言えません。

そこで、ログとアラートは集約し、キーとシークレットはそれぞれのアカウントに置くことにします。
すると、アカウントを跨ぐのはログ情報だけになるため、設定管理が非常に楽になります。
セキュリティアカウントというよりモニタリングアカウントと呼ぶ方が正しい表現かもしれません。

 

② 異常検知を行う

次に異常検知についてです。
以下がいつもと異なる場合は怪しい挙動と言えそうです。

• 頻度：シークレットの呼び出し回数が急増している
• タイミング：シークレットが深夜帯に呼び出されている
• リソース：Lambda 用のシークレットが EC2 から呼び出されている
• グループ：セットで使用するシークレットが一部しか呼び出されていない
• 認証失敗：大量に認証に失敗している
• 閲覧：アプリで呼び出しているシークレットがコンソールで閲覧された
• リージョン：同一リージョンでしか使わないシークレットが別リージョンから呼び出された

そんな時は異常検知です。
GuardDuty で検知し、Security Hub で結果をまとめ、Lambda や SNS で修復や通知を行います。
きれいな構成ですね。

 

③ 最小権限を維持する

そして最小権限についてです。
事業拡大の流れの中で、権限の強すぎるユーザーが生まれてしまうのはよくある話だそうです。
それが時にセキュリティ上のリスクとなります。

そこで IAM Access Analyzer を使用して定期的に権限の見直しを行うと、労力少なくリスクを抑えられます。

キーポリシーが適切に設定されているかを確認するために、ダッシュボードを作成する手法についても紹介されていました。

また会場から意見や質問が飛び交い、

• プロジェクトなどで必要な権限が頻繁に変わる人の権限はどう管理すべきか？
  • 変更の度にポリシーを付け替えるより、タグを認識して利用可否を判別するキーポリシーにした方が良い
• キーが最後に使用されてから一定の日数が経ったら通知する機能はないのか？
  • 詳しくは言えないが乞うご期待！

など活発な議論が交わされました。

④ 使用していないリソースを削除する

最後に未使用リソースの管理についてです。
EC2 などのサービスを削除した時、関連するキーやシークレットの削除は漏れがちです。
放置でお金がかかるだけならまだ良いのですが、これらはセキュリティ上のリスクになります。

そこで、自動で無効化するまでの期限を設定したり、一定期間使われなかった場合に通知する仕組みが提案されていました。
退職者の権限を利用して不正アクセス、、のようなニュースもたまに耳にしますが、セキュリティリソースに関しても同じことが言えますね。

 

MSPとして

スケールに耐えられる設計か

大規模になっても成り立つか、という観点は汎用性のあるテーマであると感じました。
セキュリティの話からは外れますが、MSPの業務でもスケーラビリティは課題になることがあります。
アラート数が倍増したらどうやって対応するか、社内で運用依頼が倍増したらどうやって運用設計するか、メンバーが倍増したらどうやって研修してシフトを組むか、などなど。
日常業務として、社内フローとして、組織として、どうやってスケールに対応するかは簡単に解決できることではありません。
コンセプトの話ではありますが、今回の一元管理、最小権限（責任所在）、不要リソースの削除はヒントになるのではないかと思いました。

おわりに

大規模システムのセキュリティを守る話でしたが、「良いシステムとは」「良い運用とは」という抽象化したコンセプトに思いを馳せるのでした。

おしまい