AWS Summit Japan 2024に参加してきました！

はじめに

NE株式会社の小林です！
現在SREチームでAWSアカウントのセキュリティ向上活動を行っております。
今回のAWS Summitはセキュリティセッションを中心に話を聴いてきました。
参加レポート+今後のNEはこうしていきたい!などのお話もできればいいなと思っています!

AWS Summitとは

AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、全てのクラウドでイノベーションを起こすことに興味がある皆様のためのイベントです。

詳しくはこちら

今回の参加目的

私が参加した理由は2点です。

1. 他社の方々がどのようにAWSセキュリティ対策をされているのか話を聴きたかった。
2. AWSセキュリティサービスをどのように運用していくのがベストなのか参考にしたかった。

会場の様子

入口

Partner Solution Expo

参加セッション

失敗しない!Datadogから見るAWSアーキテクチャの勘所

登壇者

萩野 たいじ 氏　Datadog Japan合同会社　AdvocacySenior Developer Advocate

セッション内容

80%の企業が過去18ヶ月間にクラウドデータ漏洩を経験しており、2025年までにはクラウドセキュリティ障害の99%が顧客の責任となると予測されています。
クラウドの所有権や責任、リスク受容に関するポリシーを導入することで問題を軽減できます。
設定忘れや潜在的な問題を把握できていないとリスクが増大するため、リスクを定義・計算して対応の優先順位を決めることが重要です。
リスクの計算式R=f(s,p,c,k)では以下の要素が考慮されます。

• s(Scenario): シナリオ
• p(Probability): 発生確率
• c(consequence): 影響の大きさ
• k(knowledge): 知識や文脈

リソースへのアクセス制御は最優先事項であり、フル権限やAdmin権限、長期未使用のアクセスキー、MFA未設定などには注意が必要です。
全員がセキュリティに関与できる方法を構築し、積極的に関与するように指導することが重要です。

AWS環境におけるセキュリティ調査の高度化と生成AI活用

登壇者

勝原 達也 氏　アマゾン ウェブ サービス ジャパン合同会社　セキュリティソリューションアーキテクト

セッション内容

セキュリティインシデントの理想は、システムとセキュリティの深い知見を活かし、ビジネス判断に集中することです。
しかし現実は、ログデータ収集などの定型作業に時間が取られ、ログの取得漏れや分析アプローチの知識不足が課題となります。
インシデント対応では、流れを把握し、有事に備えることが重要です。
インシデント検知のきっかけはAWS利用者の検知、AWSからの連絡、外部からの情報提供です。
インシデントの検知と分析にはイベントの適切な把握、膨大なログの収集・保存、継続的な脅威モニタリングが必要です。
AWSではCloudTrail、CLoudWatch logs、VPC Flowlogs、DNS Logsなどを利用し、GuradDutyで脅威検知します。
脅威検知は既知の脅威と未知の脅威を対象とし、情報収集活動や機械学習を駆使します。
継続的改善として、保護インテリジェンスや検出結果タイプの見直しを行います。
GuardDutyの検出例として、Low(偵察状態)、Medium(インスタンスの侵害)、High(アカウントの侵害)があります。
AWS環境のセキュリティインシデントは、アプリケーションドメイン、インフラストラクチャドメイン、サービスドメインに分類されます。
特に意識したいサービスドメインの観点はアクセスキーであり、アクセスキーの管理は特に重要でAWSのAPI呼び出しの認証情報は窃取対象となる重要情報になります。
セキュリティイベントの調査では、影響・範囲・原因を明らかにし、インシデントかどうかを判断します。
GuardDutyやInspectorの脅威検知情報を詳細に調査・分析する場合はAmazon Detecriveを利用して詳細に調査し、潜在的なセキュリティ問題を分析して根本原因を特定しましょう。

750+AWSアカウントのクラウドセキュリティ:脅威検知におけるスケーラブルな仕組みと運用

登壇者

花塚 亮祐 氏　株式会社サイバーエージェント　システムセキュリティ推進グループ

セッション内容

750以上のAWSアカウントのセキュリティ統制が不足していたため、セキュリティベースラインの向上を目指し、まず現場への影響が少ない発見的統制(望ましくない操作や状態の検知)から始め、脅威検知メカニズムを開発。
最初はGuardDutyを利用し、検知→通知→分析→対応のプロセスを整備。
アラートの放置が常態化しないようにアラートの対応責任者を明確化。
対応ガイドの作成や生成AIを利用してアラートの要約を行うことで対応者の負荷を減らす仕組みを導入。
セキュリティエンジニアがサポートしつつ、開発者が対応する体制を整えたことで1年半で約750のアラートが放置されずに対応できたようです。

まとめ

今回、上記セッション以外にも様々なセッションを聴いたのですが、多くの企業がエンジニア全体でAWS環境やセキュリティ管理を行なっていることが分かりました。
現在、弊社でもSREチーム中心にAWSセキュリティの向上活動に取り組んでいますが、将来的には開発チームも含め、全員がクラウド環境のセキュリティを見る・改善する体制にしていきたいと考えています。