はじめに
AWS Summit Japan 2025が2024.6.25-26に開催されました。
一部セッションは7.11まで動画が公開されています。
その中で自分が気になったセッションを備忘録的にまとめました。
Room I
AWS 製造業アワード受賞！AI と IoT で進化する製造の現場改革
- スピーカー
- 平野 健介 様
- アイレット株式会社 執行役員 アジャイル事業部 事業部長
- 平野 健介 様
- 内容
- アイレット様において行った、AIとIoT を組み合わせた最新の活用事例を紹介し、AI 導入を成功させるためのポイントについて解説
- 事例１：三菱マテリアル 加工事業カンパニー 様
- １つめの要望・課題
- 工場内の設備稼働データをモニタリングしたい
- 分析基盤とスムーズに連携することでデータを統合・分析したい
- 予想されるデータ量
- 接続設備数：約300台
- 月間レコード量20億
- アップロードに1日程度タイムラグがある/精度も不十分
- 開発・実装
- 初期開発
- AWS IoT SiteWiseを採用し、スピーディに構築
- リアルタイムのデータモニタリングが可能
- ダッシュボード表示し、クラウド一元管理を実現
- 出てきた課題
- データ量の増加に伴いETLコストの最適化が課題
- Lambdaをたくさん動かしていた
- 既存のデータ分析基盤への連携
- データ量の増加に伴いETLコストの最適化が課題
- AWS IoT SiteWiseを採用し、スピーディに構築
- 拡張
- AWS IoT CoreとAmazon Data Firehosseを採用
- Lambdaから、Data Firehoseの動的パーティショニング機能に換装し、コスト減
- 標準的なデータ構造・規格に則った形で正しく保存を可能に
- 最終的なデータはS3に保存
- AWS IoT CoreとAmazon Data Firehosseを採用
- 初期開発
- ２つめの要望・課題
- ネジなどの部品が、工程ごとに減っていく量を正確にカウントする必要がある
- 減り具合が大きいと異常 / 増えていたら重大な異常
- これを手作業でカウント
- 提案
- 画像認識AIアプリの構築
- サーバレスアーキテクチャを採用
- ネジなどの部品が、工程ごとに減っていく量を正確にカウントする必要がある
- 開発・実装
- 物体検出モデル
- Amazon SageMaker
- Amazon SageMaker Pipeline
- YOLO
- 生成AIは不適
- UI
- スマートフォンで実行可能な、サーバレスのWebアプリケーション
- スマホで撮影しクラウドにアップロードすることで、撮影・分類・計数・保存を一貫して対応
- スマートフォンで実行可能な、サーバレスのWebアプリケーション
- アーキテクチャ
- Lambdaベースで、サーバレスに
- 物体検出モデル
- 効果
- 自動化
- 作業省力化、ミス防止
- 特別な装置不要
- 新部品への拡張性
- １つめの要望・課題
- 事例２：IHI機械システム 様
- 課題
- 膨大なデータがあるのに活用できない
- 過去の帳票や設計データの検索に時間がかかる
- 帳票：過去製品の不具合のレポート等
- 多くの手書き帳票、ナレッジの共有や活用が困難
- 過去の帳票や設計データの検索に時間がかかる
- 提案
- RAGで実装
- 膨大なデータがあるのに活用できない
- 開発・実装
- 手書きのデータをテキスト化
- Amazon Bedrock
- トレーニングをすることで精度向上
- 電子データと併せてナレッジ化、カテゴリ別に分類、社内ストレージ（BOX）に保存
- Amazon Bedrock
- BOXと連携し、RAG、検索機能を実現
- Amazon Kendra
- Amazon Bedroke
- GenU
- AWS提供のオープンソース生成AIアプリケーション
- 0から作らないことでスピーディに開発
- 手書きのデータをテキスト化
- 効果
- 手書き帳票のナレッジ化
- 検索可能なデータに統合
- 検索効率の劇的向上
- 設計図面、不具合報告書などを即座に参照
- チャットUIで検索可能
- 手書き帳票のナレッジ化
- 課題
- 事例３：製品サポート事例
- 課題
- 人手での問い合わせ対応は、数日必要
- 問い合わせ増加により担当者の負荷増加
- 開発・実装
- UI
- Teamsのチャットボット
- メンションで指定して質問することで、質問内容、データ参照元リンクを添えて回答
- 過去の応対履歴を一覧で見れるダッシュボード
- 後追いで見て、問題があれば個別にフォロー可能
- Teamsのチャットボット
- UI
- 効果
- 60%は向上
- 3－4日の対応が、数秒で回答
- 10%は誤った回答
- ダッシュボードで後藤を検知し、人手でフォロー連絡
- 30%は自動回答不可
- わからないものはわからない、というように回答する
- 人手問い合わせのフローに誘導
- 60%は向上
- 発展
- Amazon Lex経由で、音声質問・回答
- 製造現場では、手が塞がっている・汚れていることを視野に
- Amazon Lex経由で、音声質問・回答
- 課題
損保ジャパン × デロイト トーマツ：クラウドで変える損保業界のサプライチェーン -業界共通基盤の第一歩、レンタカー手配 DX-
- スピーカー
- 坂口 健治 様
- デロイト トーマツ コンサルティング合同会社 金融事業部 保険ユニット シニアマネージャ
- 杉田 浩之 様
- 損害保険ジャパン株式会社 保険金サービス支援部 SJ－R 推進室 戦略グループ 課長代理
- 坂口 健治 様
- 内容
- 作成したシステムを業界共通基盤まで昇華
- 車が使えなくなった際にレンタカーを手配するシステム
- 各レンタカー業者に、ユーザーに適した条件で配車できるか確認する必要がある
- 取り組もうと思った理由
- 損保業界共通の課題と対応
- 電話・FAX主体の運用が非効率である、周知の事実
- 旧態依然の延長ではなく、抜本的なオペレーションの見直し
- 構築システムが、保険会社・レンタカー会社に受け入れてもらえる保障がない
- 開発工程で、ユーザの声をしっかり反映
- 電話・FAX主体の運用が非効率である、周知の事実
- 業界からの声
- 当初は共通化する予定がなかった
- レンタカー会社からのニーズ
- 自社システムとして利用開始後、同業他社の耳に届いていた
- レンタカー会社から評判の声が、同業他社に寄せられていた
- 損保業界共通の課題と対応
- 車が使えなくなった際にレンタカーを手配するシステム
- 自社システムとしての成功のポイントと難所
- PoCでの検証と検証結果の反映
- レンタカー会社と自社現場部署の協力でニーズ確証を得る
- 直観的に操作可能でシンプル
- 機能を厳選し、直観的なシステムを目指す
- 本当にやりたいことのみ実装
- レンタカーユーザーへのきめ細やかなフォロー
- レンタカー会社のオペレーションに組み込めるよう、密に連携
- 問い合わせに対応するため、デモ動画作成
- 活用状況の見える化
- 定量的な利用状況
- 現場の活用方法をインタビューし、好取組事例として横展開
- PoCでの検証と検証結果の反映
- 共同プラットフォームとしての成功のポイントと難所
- 開発プロダクトの合意形成
- 競合他社と同じ方向を向いて開発
- コミュニケーションの質と量を高め、信頼関係を築く
- 最低でも週1回の会議
- ビジネス効果を出しやすくするシナリオ作成
- 投資費用回収・運用費削減と保険会社の参入のしやすさを両立させるシナリオ
- 3社目以降を参入する取り組み
- ニュースリリースをきっかけとした関心・問い合わせ
- 迅速な利用開始：契約手続き後、速やかに利用開始できるよう開発工程を省略する
- リスクの低減：既に利用実績があるシステム
- 手厚いサポート：参入保険会社向けに、利用実態に基づいたアドバイスを提供し、リリース後の不安を解消
- 競合他社と同じ方向を向いて開発
- 開発プロダクトの合意形成
- 業界共通にするポイント
- 誰が最初にこのマーケットへ参加するか
- 誰が参加して、共通基盤を発展させるか
- 今回は大きい2社：損保ジャパンと東京海上 が最初だった
- マーケットの標準になるように環境を整える
- 後続の参加者が安心して参加できるように環境を整える
- 誰が参加して、共通基盤を発展させるか
- ビジネスモデルが透明で公平で、経済合理性を持っていること
- 標準である、だけでは不足
- 収益観点、投資コストの観点
- これらを開発してリリースして運用できるか
- 誰が最初にこのマーケットへ参加するか
- 作成したシステムを業界共通基盤まで昇華
Room M
日産自動車 CCoE が大規模インフラをクラウドファーストにするまでの道のり
-
スピーカー
- 竹原 陽道 様
- 日産自動車株式会社 グローバルデジタルプラットフォーム本部 IT インフラストラクチャー デジタルワークプレース&エンタープライズアーキテクチャー部 (兼) ビジネスシステムソリューション本部 デジタルプラットフォーム部 シニアマネージャー
- 竹原 陽道 様
-
日産の現在
- 業務を支えているシステムの66%がAWSで稼働
- 新規業務アプリケーションは原則クラウド上に構築するのがルール
-
クラウド化への歴史
- 2017-2018
- クラウド化号令
- 2019
- 2月 モダン環境（Mode2：攻めのIT）リリース＋社内勉強会実施
- 共通基盤（データ、バッチ等）との接続を用意しておかず、改修を強いられるため、全く進まなかった
- 9月 リフト環境（Mode1：守りのIT）リリース
- 共通基盤をクラウド上に用意
- 2月 モダン環境（Mode2：攻めのIT）リリース＋社内勉強会実施
- 2021
- アプリ・インフラの老朽化に伴ってクラウド化号令
- 2023
- 6月 クラウド利用量がオンプレミスを追い抜く
- 9月 Cloud CoEの立ち上げ
- 2017-2018
-
Cloud CoEの取り組み概要：2023年9月
- 状況
- クラウド化50%達成
- シフトを進めたが、モダン化できていないシステム
- 残りはクラウド化が難しい
- メインフレーム、老朽機
- 個別クラウド利用の拡大
- クラウド化50%達成
- 取り組み概要
- フロントにコンサルテーション：相談窓口を用立て
- 以前はシステム開発部隊が、各窓口に問い合わせしていた
- 認証機能、ネットワーク、クラウド環境、etc,,,
- 問い合わせ先を探すのが大変
- コンサルティングチームを立ち上げ、問い合わせ窓口を一本化
- わかることは即答、わからないことは各窓口に代理で問い合わせ
- プロジェクト支援を強化
- 問い合わせ回答のナレッジ蓄積
- 開発者ニーズの把握：以降のCCoEの活動につながる
- 以前はシステム開発部隊が、各窓口に問い合わせしていた
- サービス開発部隊を用立て：ニーズに合わせた環境開発出来る
- Mode1：80% Mode2：19%
- 当てはまらない1%は個別AWSアカウントで対応
- 理由
- Mode1,2で利用できないサービスを使いたい
- マネコンの1%の機能しか使えなかった
- NWを自由に使いたい
- Mode1,2のサービスレベルでは不足
- メンテナンスの時間帯がシステム要件と合わない
- Mode1,2で利用できないサービスを使いたい
- 課題
- ガバナンス
- 理由
- 当てはまらない1%は個別AWSアカウントで対応
- ModeXをリリース：2024年6月
- 必要最小限のガバナンスを担保
- Service Control Policy,Security Hub,GuardDuty,etc
- 最小限の制限のもと、自由なクラウド利用を提供
- 開発者自身の責任で運用
- 必要最小限のガバナンスを担保
- Mode1：80% Mode2：19%
- ルール・ガイドライン
- クラウドに即したルールへ改定
- プロモーション・トレーニング
- コミュニティを形成して促進
- インフラ、アプリ、AWSで組成
- フロントにコンサルテーション：相談窓口を用立て
- 状況
-
まとめ
- 組織的に活動することでクラウド利用促進を加速
- トップダウン、ボトムアップ
- ユーザーニーズを拾う仕組みづくりで、効果的な戦略が立案できる
- プロジェクト初期から支援すると、ニーズを捉えられる
- ボーダーを決めて開発者にクラウドを開放
- セキュリティ部隊との密なネゴシエーションが必要
- 組織的に活動することでクラウド利用促進を加速
-
今後
- 情報システム部門以外のクラウド利用
- セルフサービス型のAWS環境づくり
- 開発者のため、セルフサービス型のインフラ・アプリ環境プラットフォームを提供
Room N
電力システムなのに毎週リリース!? ENEOS が考える内製開発の価値とポイント
- スピーカー
- 原田 耕佑 様
- ENEOS株式会社 中央技術研究所 デジタル研究所 デジタル事業開発グループ グループマネージャー
- 原田 耕佑 様
- 内容
- 大型蓄電池の運用計画策定システムを、内製開発した際のポイント
- AWS活用ポイント
- 徹底してセキュアなアーキテクチャ：電気系統システムは要求セキュリティレベルが高い
- 完全サーバレスで、サーバ管理から解放
- 対抗先ごとにVPCを立ててネットワーク分離
- Direct ConnectやVPCなどで
- AWS Security Hubで設定監査+脆弱性検知
- すべてをterraform+GitHub Actionsで構築
- AWWS Countdown Premiumの活用
- 厳しいセキュリティ要件を満たしているかレビューが必要
- 第三者視点でのレビューができる
- 第三者による設計レビュー履歴は説得力ある材料に
- 設定の改善による運用負荷低減
- 担当エンジニアが、アプリ仕様を読み込んでパフォーマンス含めたレビュー
- 週次MTGによるプロジェクトのペースメーカー
- ローンチタイミングでエンジニアが待機
- 厳しいセキュリティ要件を満たしているかレビューが必要
- 徹底してセキュアなアーキテクチャ：電気系統システムは要求セキュリティレベルが高い
- なぜ内製化するか
- 内製化の価値
- 既存事業が大きすぎる/リスクの外部化の習慣などで、IT内製とは相性が悪い
- それでも、以下の価値がある
- 昨今の業務は、ほとんどソフトウェアを用いている
- 「変更に強いシステム」は、良さがコードのみに現れるため、内製化が良い
- もっとも重要で変更に弱い部分は「スキーマ（データ定義）」であり、事業ドメイン知識と密接に結びつくため、内製化により品質を高める
- 業務フローの実現が業務の構造化になり、業務の改善意欲につながることで、ディベロッパーへのリスペクトを持つカルチャーになる
- 優秀なエンジニアが集まりやすくなる
- 楽しい内製のためのTips
- 言い出しっぺがPO/PdMをやる
- その会社にとって新たな取り組むであればあるほど、戦略立案者と実行部隊を分けた瞬間に勢いを失う
- 内製におけるPO/PdMは、ドメインとITのブリッジ役として重要
- 忙しい人がなりがちだが、深くコミットが必要
- 企画者が、長期間の厚いコミットをささげられる状況にないのであれば、内製しないほうがよい
- 案件を見極める
- 要件が安定しているなら、外注やウォーターフォールは効率的
- 「要件定義が面倒だからアジャイル」はNG
- 作ったシステムの改善に価値があり、そのコストを払える案件であること
- 内製化は決してコスト削減にはならない
- 改善コストを払い続ける価値がある案件化を見極める
- 要件が安定しているなら、外注やウォーターフォールは効率的
- 発注側もリスクを取る
- 内製＝システムが完成しない/低品質になるリスクを取ってアジリティを得る
- 意思決定層まで含め、これを理解・合意してもらう必要がある
- 理解を得るための活動はサボらない
- 予実の差分を詰められるような環境でアジャイルをやっても失敗する
- KPIで理解をしてもらう
- 内製＝システムが完成しない/低品質になるリスクを取ってアジリティを得る
- チーム作りがすべて
- 結局 人
- PLは新しい人との出会いをちゃんと作る
- タレントをバイネームでアサインできるようシビアに調整
- 社内でも社外でも
- モダンなツール、モダンな技術スタックの環境を提供する
- 全員でドメインにdeep diveする
- 内製の強み＝開発チームとドメインが近い
- より近づけるような努力が必要
- POがIT側であれば、業務経験・現場理解を積んで価値を高める
- 事業部門と内製部門の兼務という、人事レベルで取り組みの形
- 内製の強み＝開発チームとドメインが近い
- 属人化を恐れすぎない
- 競争力を持つ＝他社と差異化する
- 属人化は当然
- 作りきって、良いものであるとわかった時点から、オペレーションを作っていっても間に合う
- 属人化を抑止するような組織には、尖った優秀な人材は来ない
- 競争力を持つ＝他社と差異化する
- 言い出しっぺがPO/PdMをやる
- 内製化の価値
「変化を競争力に変える」アジャイルとクラウドで実現する、自律的に成長し続ける組織のつくり方
- スピーカー
- 佐藤 耕平 様
- 株式会社NTTドコモ コンシューマサービスカンパニー 第一プロダクトデザイン部 技術戦略担当 担当部長
- 西本 暁洋 様
- 株式会社NTTドコモ コンシューマサービスカンパニー 第一プロダクトデザイン部 技術戦略担当 担当課長
- 佐藤 耕平 様
- 内容
- 自律的に成長する組織のポイント
- リーダーのトーンセッティング
- リーダーがパーパスを言語化して発信
- プロダクトデザイン
- エンジニアとしてあるべき姿
- 行動規範として、してよいことを言語化
- 定期的に発信し続け、リーダーの考え方を組織に浸透させる
- 朝礼の場でパーパスを語る
- 全社チャンネルでエンジニア論などを発信
- 一丸となる土壌が作り上げられる
- リーダーがパーパスを言語化して発信
- 「仕組み」と「場づくり」による実践
- 仕組み：PD版SECIモデルを策定（暗黙知と形式知を相互交換しながら組織を強めていく）
- 以下のサイクルを回す
- 感覚知・感覚値を「標準化」して比較できるようにする
- 開発チームが備えたいケイパビリティを4テーマ/80項目のチェックリストとして規定
- 「UI/UX改善が2週に1回できていますか？」
- 何ができていて、何が不十分なのかを明らかにする
- 半期に一度実施
- 開発チームが備えたいケイパビリティを4テーマ/80項目のチェックリストとして規定
- データとして「可視化」する
- チェックリスト回答結果をダッシュボードで可視化
- 他のチームの状況も把握し、自チームの改善につなげる
- 可視化した内容からの示唆を「形式化」して型を作る
- 良い型をベストプラクティスとして組織全体に「横展開」する
- ノウハウとしてイントラに掲載
- 勉強会として横展開
- 月2回以上
- 感覚知・感覚値を「標準化」して比較できるようにする
- 仕組みを浸透させる工夫・仕掛け
- 皆で作る
- 検討初期段階から、組織トップや開発リーダーを巻き込む
- 事業の結びつきを示す
- 「開発チーム力が高い＝ストア評価も高い」
- 成績表ではなく、改善に向けたきづき
- 他との競争ではなく、全体の成長のための仕組み・ツールであることを説明、理解
- 皆で作る
- 以下のサイクルを回す
- 場づくり：3観点から場を提供
- お客様の理解：求められていることがわかる
- デザイン思考
- お客様の声分析ツール
- 分析項目を集約して一覧化
- AppStore、Google Play Store、X などの分析
- 競合プロダクト比較
- 社員の声
- 利用者分析
- Xによる障害検知
- 寄せられたお客様の声分析
- AppStore、Google Play Store、X などの分析
- 分析項目を集約して一覧化
- 学びと実践：やり方を知っている・出来る
- 学習機会の提供
- 研修/勉強会、AWS勉強環境
- コミュニティ運営
- アジャイル/クラウドネイティブの実践
- 学習機会の提供
- 発信と称賛：フィードバックを得る・成果を分かち合う
- 外部発信の奨励
- 発信の見える化
- 社内のサイネージ等で展開
- 表彰/称賛の機会
- お客様の理解：求められていることがわかる
- 仕組み：PD版SECIモデルを策定（暗黙知と形式知を相互交換しながら組織を強めていく）
- 経営とのブリッジ
- 開発組織の価値がプロダクト価値を生み、プロダクトが事業価値を生む
- 開発組織の価値を事業価値に直接変換はしない
- 3階建ての構造で事業の状態をダッシュボードで可視化し、経営と現場をつなげる
- 開発組織の価値がプロダクト価値を生み、プロダクトが事業価値を生む
- リーダーのトーンセッティング
- 自律的に成長する組織のポイント
ニコニコの大規模セキュリティ改革
- スピーカー
- 味戸 大樹 様
- 株式会社ドワンゴ 技術本部 クラウドエンジニアリング部 第一セクション マネージャー
- 味戸 大樹 様
- 内容
- サイバー攻撃とその対応
- 2024年6月、サイバー攻撃が発生
- その瞬間、何が起きているかわからなかった
- 急激なスピードでシステムダウンしていくことだけ
- 障害なのか、攻撃なのかも判別できない
- その瞬間、何が起きているかわからなかった
- サイバー攻撃発生時、NW遮断し、AWS環境を隔離
- 新たに攻撃を受けないように/更なる被害拡大を防ぐため
- オンプレとのDirect Connectを遮断
- インターネット経由のルートも遮断
- VPS間の遮断も、準備はしていた
- シャットアウトによるAWS環境の保護
- 安全が確認できるまで、触れる人間を限定
- 不正ログインなどの被害拡大を防ぐ
- あらゆるリスクに鑑み、原則すべての認証情報を無効化。一時的に完全隔離状態
- IAM Identity Center
- IAM
- Session Managerなど
- 被害状況や攻撃手法がわからなかったので、素早く全部シャットアウト
- MFA、外部プロバイダ利用ログインなども例外にしない
- スクリプトで抽出できるようなログイン情報は全部無効化
- パスワード、キーはリフレッシュ
- AWS環境の点検を開始
- 攻撃の痕跡がないか確認
- Cloud Trailのログから不審な挙動を調査
- ネットワークメトリクスも確認
- 外向きの大容量通信
- 不審なパケットの有無
- 日ごろから可視化できるようにしておくべきであった
- ネットワークメトリクスも確認
- GuardDuty、Detectiveで、不審なアクティビティの検知
- Cloud Trailのログから不審な挙動を調査
- AWSや外部専門事業者の協力を受けていたので、AWS環境には被害がなく、復旧可能へ
- 攻撃の痕跡がないか確認
- 2024年6月、サイバー攻撃が発生
- セキュリティ改革の全貌
- 目指したセキュリティ改革
- 予防できる状態
- 合理性に基づき、侵害の範囲を可能な範囲で
- 検知できる状態
- 万が一、侵害が発生した場合
- 対処できる状態
- 侵害を検知した場合
- 予防できる状態
- セキュリティプラットフォーム
- マルチアカウントアーキテクチャ
- 内部で相互にアクセスは、デフォルトではできない
- インシデント発生時の影響範囲の限定化
- チームごとのコスト管理
- 柔軟にアカウント・環境の追加ができるためスケールに強い
- ユーザー権限管理の一元化
- 内部で相互にアクセスは、デフォルトではできない
- セキュリティガイドライン
- 前提
- ガバナンスの課題
- システムごとに採用するサービスも技術スタックも自由
- 統一的な基準を作るのは非現実的
- AWSサービスに合わせたセキュリティガイドラインを策定
- 組織全体で定めているガイドラインとは別
- サイバー攻撃後はベースラインを引き上げて運用
- ガバナンスの課題
- 対策
- 予防
- セキュリティリスクとなる要素の
- 可視化（発見的コントロール）：不備を可視化して対処
- Security Hub
- 違反情報の集約・通知
- 大量の違反で、現実的に対処できない
- Security Hubの標準の活用
- 特性に応じた独自の基準の策定
- 大量の違反で、現実的に対処できない
- 違反情報の集約・通知
- Trusted Advisor
- Control Tower
- Security Hub
- 制限（予防的コントロール）
- Service Control Policy(SCP)
- 組織独自の要件を実装可能
- Cost Explorerは見せたいが、Bilingのみ不可
- 組織独自の要件を実装可能
- IAM
- Control Tower
- OUごとに許可リージョンを制限
- マルチアカウントアーキテクチャにてガバナンスを効かせられるサービス
- Service Control Policy(SCP)
- 可視化（発見的コントロール）：不備を可視化して対処
- セキュリティリスクとなる要素の
- 検知
- GuardDutyによる組織横断での監視体制
- 脅威検出
- プロテクション
- ランタイムモニタリング
- マルウェア保護
- 検知すべきイベントを精査し、パイプラインを構築
- 検知イベントをEventBrigdeでハンドリングし、チャットで通知
- GuardDutyによる組織横断での監視体制
- 対処
- 侵害検知後の動きを取り決めておく
- 24365体制で、以下対処フローを実現しなければならない
- 侵害の検知
- 専門チームによる調査、分析
- 誤検知だった場合：対応終了。ナレッジ化。誤検知予防
- 攻撃/判断不明だった場合：インシデント対応開始
- 緊急緩和策の実行
- 関係各所への連絡
- 侵害状況の調査
- 侵害に対処するための体制
- 自社のエンジニアチーム
- メインのトラブルシューター
- 業務知識
- ワークロードへの理解
- 外部セキュリティ監視事業者
- トラブルシューターへの支援
- セキュリティ関連知識
- インシデントに対する理解
- サービスが登場：Security Incident Response
- AWSに精通、トリアージや精査もやってくれる
- 24365体制で、インシデントケースとして対処してくれる
- 自社のエンジニアチーム
- 利用すべきセキュリティサービス
- 必要なサービスに絞って採用してもよい
- セキュリティ以外のサービスと組み合わせて連携
- 予防
- 前提
- マルチアカウントアーキテクチャ
- 目指したセキュリティ改革
- まとめ：セキュリティ対策に必要なこと
- 保護したいワークロードの全体を捉えた上で、予防・検知・対処の各ステップに対し答えを持つ
- 環境ごとにどれだけ対策するのか、決めておく
- 初動対応の重要性を理解し、事前に備えること
- 現実的に想定される攻撃に対し、切り離し・隔離の方法など事前の準備をしておく
- 継続的に投資し続ける覚悟を持つ
- 同じ対策が使い続けられるわけではない
- 保護したいワークロードの全体を捉えた上で、予防・検知・対処の各ステップに対し答えを持つ
- サイバー攻撃とその対応
おわりに
取り急ぎ、事例セッションを見てまとめてみました。
去年に引き続き、生成AIがテーマのセッションが多かったですが、自分はCCoEや組織などに注目していました。
この記事がどなたかのお役に立てれば幸いです。