この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさんこんにちは、東京オフィスの芦沢です。
Security JAWS 第23回が開催されましたのでレポート致します。
Security-JAWS【第23回】 [AWS Security Roadshow Japan 2021] 特別拡大版
動画
レポート
Session1：パネルディスカッション アマゾン ウェブ サービス ジャパン株式会社 桐山隼人さん シンプレクス株式会社 岸野 秀昭さん 株式会社ソニー・ミュージックエンタテインメント 田代 雄亮さん Japan Digital Design 株式会社 唐沢 勇輔さん
- 議題1：重要データの保護について、皆様の企業にとってどんなデータ？どうやって保護してる？
- 田代さん
- 重要データ=個人情報
- 最低限のセキュリティはガードレールで保証
- 海外展開ではGDPRを重視など、場合によってセキュリティのレベルを変えたりする
- 唐沢さん
- 重要データ=法人顧客の決済データ
- 例）オンラインレンディングによる信用スコア(2000万件ある)
- 公開しなくてもいいデータなのでネットワークを絞り、権限分離、監視を定石通り実施
- 分析することが目的なので、分析者の権限はある程度自由に
- 一方でデータは簡単に外へ持っていけないようにガバナンスを設定
- 重要データ=法人顧客の決済データ
- 岸野さん
- 重要データ=顧客システム内の個人情報
- 例）口座情報など
- どうやって守る？
- 構築のIaC化による品質担保
- テストコードの半自動化による品質担保
- 端末からのデータの閲覧やデータ持ち出しには承認が必要で、簡単にデータへたどり着けないようになっている
- 田代さん
- 議題2：登壇で言い残したこと
- 唐沢さん
- そもそもクラウドで何をやりたいんだっけ？を考えてからセキュリティ要件を考えよう、ということ
- 早めな相談はよくあるが、相談者の方の目的、ビジネス要件がクリアになっていないことが多い
- グループ会社との取引が多いので、相談前に煮詰まっていないことが多い。
- 二人三脚で進める意識はあるが、それにしても、、、ということが多い
- そもそもクラウドで何をやりたいんだっけ？を考えてからセキュリティ要件を考えよう、ということ
- 岸野さん
- 本編ではCCoEの話をしたが、本来は技術的な話に触れたかった
- プロジェクトに入りこもうとする前の話をここでする
- きっかけ
- 外部からだとセキュリティ品質の担保をどこまでやるのか、の判断が難しい
- だからプロジェクトに入り込んでみた
- 以前は
- セキュリティチーム単体で決めることは難しかった
- 性能重視、機能制約なしで暗号化をどこまでやるかなど
- やってみてどうか
- プロジェクトに入り込んだことで、プロジェクトの実態に即したセキュリティ対策をすることができるようになった
- プロジェクト内でのセキュリティな困りごとや知見をセキュリティチームへ持ち帰ることができるようになった。
- 田代さん
- プロジェクトの立ち上がりの件数が多い（年間100件以上）のでセキュリティのレビューをやっている
- 中に入ってやる、というところまではできていない
- セキュリティと事業はプロジェクト毎に要件がバラバラ
- バランスを見極めてやっている
- 唐沢さんの「結局何やりたいんだっけ？」な話は田代さんも思うところがある。
- 人材不足の問題をよく感じる
- ソニーミュージック様では、セキュリティチームはもともとビジネス部門から始まったもの
- セキュリティチームとして、ビジネスとセキュリティの橋渡し的な役割をしている
- セキュリティチームの人材は不足しています！（再）
- ビジネスもセキュリティも両方わかっている人が担当にならないといけない
- プロジェクトの立ち上がりの件数が多い（年間100件以上）のでセキュリティのレビューをやっている
- 唐沢さん
- 議題3：セキュリティ人材の話
- 岸野さん
- 今まではアプリよりもインフラレイヤーをやってきた
- アプリレイヤーのセキュリティの知見があまりないので、アプリケーションチームの人たちに来てほしい
- けどなかなか難しい
- 定例会をやるなどして知見を増やしている
- 少ない時間で知見を最大限引き出す
- 唐沢さん
- セキュリティチームは3人くらい
- プロジェクト数が多いわけではないので、なんとか回っている
- だが、アーキテクチャまで考えられる人が不足している
- アーキテクチャレビューしていると自分で設計したくなることが多い
- エンジニアサイドでそこまで考えられる人が欲しい
- 絶賛採用中です！
- 田代さん
- ガードレール周りのチームは4人体制（全員兼務）
- 基本的に自動化・効率化しているので、アカウントが増えても人を増やさなくて済んでいる
- どんなところを自動化？
- SecurityHubの設定など
- コンテナを使っていたので短時間で対応できた
- このあたりはDay2のセッションで話すそう
- 岸野さん
- 議題4：セキュリティ自動化の話
- 唐沢さん
- 自動検知はやっているが、自動修復はやっていない
- アカウント払い出しをCFnにしたり、それに監視設定を追加したり
- root権限の検知などは環境払い出し時の段階で検知できるようにしている
- 岸野さん
- 自動修復はやっていないが、SecurityHub、Config Ruleのような自動検知はやっている
- 検知したらその場で直してもらう、という運用フローが整備されている
- 田代さん
- 自動修復までやっている
- SSHルールの不正等あれば自動で修復して再設定できない、までやっている
- 自動修復をやっても問題にはなっていない
- 事前に何度も周知しているから
- AWSJとの定例で全アカウントオーナーに周知している
- AWSJ立ち会いの場でで周知することで、オフィシャル感があり説得力を増しているかも？
- 唐沢さん
- Sli.doからの質問：社内政治的な邪魔でセキュリティ施策が実施できない時はどうする？
- 唐沢さん
- 政治的要因でできないなら、政治的に戦う
- 社長など上の人の力や、外部の力を使う
- まずはその人と話すとこから
- 田代さん
- 事故が起きた後は、話が通りやすい
- 他社の事故でもOK
- 事故の後はセキュリティ対策でやりたいことをまとめて提案する
- 岸野さん
- 他社の事故や事例などを社内で共有する
- セキュリティレベルを可視化する
- 桐山さん
- 登壇した実績によって社内への雰囲気作りに役立てているという話もあるよ
- 唐沢さん
- 最後に伝えたいこと
- 岸野さん
- セキュリティについて考えた結果クラウド使おう、になることもあるよ
- 田代さん
- 日本はセキュリティ後進国だと思われているかもだが、セキュリティ活用実績はたくさんあるぞ
- 唐沢さん
- セキュリティ担当は孤立しがちでビジネス・IT部門と対立しがちだが同じ想いを共有できてよかった
- クラウドはセキュリティがやりやすいということを実感
- 岸野さん
感想
セキュリティ自動化のお話がとくに印象的でした。
自動検知まではいけるが、自動修復まで実装するにはなかなかハードルは高く、社内政治をうまくやる必要があるようです。
そして、セキュリティ人材ってどこも足りてないよねって話も聞けました。
Session２：AWSを攻撃したらこうなるのでちゃんと対策しようねって話 クラスメソッド株式会社 AWS事業本部コンサルティング部 シニアソリューションアーキテクト 臼田 佳祐さん
登壇ブログはこちら
- 今日のテーマ
- 脅威を理解して適切に対策してもらう
- AWSの環境を攻撃されたらどうなるの？
- 色んなものへサヨナラすることになる
- 情報
- 資金
- 会社の信用
- 色んなものへサヨナラすることになる
- 攻撃の一例（ブログ）
- AWSの一般的な3層構造のアーキテクチャ
- 攻撃者がアプリケーションの脆弱性(SSRF)をついてIAMRoleの認証情報を取得
- IAMRoleがうっかりS3を見ることができる権限があった
- S3にもうっかりIAM Userの権限情報があった
- などなど
- 最終的に、、、
- BackDoor用のユーザーの作成
- コインマイニング用のEC2インスタンスを立てる
- EC2に侵入してRDSの機密情報を窃取
- こんなことが十分発生しうる
- 根本の攻撃自体はアプリケーションの脆弱性だが、AWS構成自体がベストプラクティスに沿っていないかったため、最悪の結果になってしまった
- 一つ一つは脅威ではないが、組み合わさると脅威になる
- AWSセキュリティ対策にはAWSの脅威を知る必要がある
- AWSの脅威
- 誤った情報の公開、アクセス許可
- 試しによくわからず使い始める、ということをしがち
- ローカルの環境とは違って、AWSは最初から外部に公開されている環境
- 試し使いでも理解して使い始める必要がある
- 資金の浪費
- 従量課金で安く使い始められるが、適切な管理がないと莫大な請求に
- 誤った情報の公開、アクセス許可
- AWSの脅威
- 実際のインシデントの事例
- アクセスキー漏洩の話（ブログ）
- GitHubに乗ってから10分で漏洩
- 個別のセキュリティ対策
- 全内容はブログにまとられています
- IAM
- 仕組みとして漏洩を防止
- git-secrets（ブログ）
- PermissinBoundary
- SecurityHub
- GuardDuty
- 脅威検知
- AWSドキュメントに検知時の対応はわかりやすく書いています
- 初動対応例
- IAMのクレデンシャル無効化
- Security Groupのルール変更でEC2の隔離
- S3パブリックアクセスの無効化
- 運用についてのブログ
- 脅威検知
- Amazon Detective
- 脅威検知時の調査フェーズをまるっと対応できる
- 内部のグラフDBで関連付けしてくれる
- 関連イベントを辿ったり。関連APIを集計&検索できたりする
- ガッツリしたデモのブログ
- おまけ：WAF
- CAPTCHA認証ができるようになった
- まとめ
- 脅威を理解し適切に対応する
- 防御だけでは足りない
- 検知してからの対応も準備しておく
- Sli.doからの質問
- 質問：本番・開発でのセキュリティ設定の違いはどう考えるべき？
- 開発環境では緩めの権限を渡す
- 最低限できないことはブロックしておく
- 本番環境の時には最低限の権限
- 開発環境では緩めの権限を渡す
- 質問：S3のセキュリティを学ぶには？
- AWS公式のセキュリティベストプラクティスというユーザーガイドが充実している
- 質問：自社のセキュリティの脅威を分析するには？
- 本来は、ストライドなど脅威分析のモデルを使う
- AWSだと加えてSecurityHubを使ったAWS観点でのアプローチができる
- 質問：本番・開発でのセキュリティ設定の違いはどう考えるべき？
感想
AWSが攻撃されたらこうなるぞの説明や脅威からAWS環境を守る方法などを個別のサービスごとに説明していたり、セキュリティ初心者の私にもでもかなりわかりやすいセッションでした。
関連ブログもたくさんありますが、どれも非常によくまとまっているので、まずひととおり読むことからがスタートラインでしょうか。
最近AWS認定のSCSを取得したのですが、ここで挙げられているサービスやブログを網羅しておくと試験勉強にもかなり役立つなーとか思ったりもしました。
Session３：閉域要件におけるS3周辺ポリシーの組み合わせ方 みずほリサーチ&テクノロジーズ株式会社 松尾 優成さん
- 話すこと
- 閉域用件でS3のデータ流出の防止をどう防ぐか（予防的統制観点）
- ポリシーを組み合わせてどのようにS3のデータ流出を防ぐか
- 話さないこと
- データ流出時の発見的統制観点
- S3 ACLやKMSの詳細設定
- S3以外のデータ流出対策
- オンプレのデータ流出対策
- 構成概要
- オンプレからS3に格納した情報をEC2で分析して還元する
- ユーザごとにS3バケットがあり、ユーザが増えるとS3も増える
- 閉域網でもデータは流出する、という話
- 着目するポリシー
- IAMポリシー
- VPCエンドポイントポリシー
- バケットポリシー
- データを保有するコンポーネント毎に流出対策を考えてみる
- 閉域用端末
- EC2
- S3
- VPCエンドポイントを利用するアクセス者側で考える
- VPCe利用者（閉域用端末、EC2）のアクセス権限
- ここからIAMポリシーについての細かい話
- IAMポリシーのAction句は最小権限
- Resource句にはワイルドカードを使ってる
- なぜワイルドカードを使うのか？
- IAMロール修正時にミスがあるとめんどくさい
- でもIAMポリシーにワイルドカードがあると不正経路につながる
- ワイルドカードを使いつつ、アクセス先のS3を自社アカウントに制限したい
- こんなアップデートが
- IAM条件キーのs3:ResourceAccountを使って特定のAWSアカウントが所有するバケットに制限できる
- 漏洩のリスクが減る！
- でも、社内クレデンシャルを持ち込まれると？
- 流出してしまう
- しかもS3データイベントがCloudTrailに記録されない（かも）
- クレデンシャル持ち込みパターンでも漏洩を防ぐには
- s3:ResourceAccountをVPCエンドポイントポリシーで使用すればOK
- Deny以外にAllowも設定が必要
- S3バケット：正常経路の洗い出し
- 不正経路はいろいろあるので正常経路を洗い出したい
- ざっくりと3パターン
- アカウント内の他のサービス
- パブリックアクセス
- 他アカウント
- バケットポリシーだけで制御する場合
- スイッチロール時にPrincipalだとワイルドカードが使えないので、aws:useridを使用して制御（参考ブログ）
- バケット自体のARNをResource句に指定すると設定ミスの時にrootユーザ以外でバケットを触れなくなるので注意
- バケットポリシーだけだと煩雑なのでアクセスポイントを使うといいよ
- 各アクセスポイントで設定、特定経路以外をDeny
- 紹介したんだけど、実は、使いたかったけど使えなかった
- 以前はアクセスポイント利用がARN形式のみをサポート
- アプリケーションやミドルウェアにより使えない場合があった
- 現在はアップデートにアクセスポイントエイリアスを使えるようになった
- 結論、S3もバケットポリシーで特定経路以外をDenyすればOK
- ポリシー関連まとめ
- IAMポリシー
- s3:ResourceAccountで社外バケットへのアクセスをDeny
- VPCeポリシー
- aws:PrincipalAccountでクレデンシャルの持ち込みをDeny
- バケットポリシー
- aws:sourceVpceなどで特定経路以外をDeny
- IAMポリシー
- VPCe利用者（閉域用端末、EC2）のアクセス権限
- 余談：発見的統制も相当な体力、な話
- CSPMの製品を導入
- 多数のルールから適用対象、カスタマイズ対象を選定
- SecurityHubのCISベンチマークを遵守
- ConfigやCloudWatchで通知をぽちぽち実装
- CSPMの製品を導入
- 全体まとめ
- NW的に閉域網でもデータ流出のリスクはある
- S3周りで気をつけたい点
- 社外バケットへのアクセスは防げるか
- クレデンシャルの持ち込みを対策できるか
- 機微情報を扱うバケットはアクセス経路を限定しているか
- 課題：境界防御からの脱却を夢見る
- Sli.doからの質問
- 質問：バケットポリシーの記載ミスでも5営業日かかる？
- 緊急で即時でやってもらえる
- 質問：SecirutyHub+CSPMでコストに見合った成果はある？
- 最初はCSPMを使って独自でやってたけど、後から社内ルールでSecurityHubを追加
- 見合ったものがあるか、というと微妙
- 質問：バケットポリシーの記載ミスでも5営業日かかる？
感想
閉域網における流出経路の流出パターンをしっかり想定できていて、すごいなと思った。
紹介されていた実際の設定事例も知見の塊。
Session４：DMMでAWSセキュリティガードレールを作ったので、開発者がAWSセキュリティをチェックする文化を広げていきたい 合同会社DMM.com 西山 渉さん
- 話すこと
- DMMでAWSecurityガードレールを構築
- AWSSecurityガードレールを支える技術
- 開発者がセキュリティをチェックする文化
- 第1話：DMMでAWSecurityガードレールを構築
- AWSセキュリティガードレールとは？
- セキュリティ品質担保のための検知の話=発見的統制
- DMMについて
- 67チーム、AWSアカウント300以上
- 要件
- AWSへのセキュリティ脅威の検知
開発者にセキュリティチェックしてもらう
- はじめに承認とるときの話
- AWSセキュリティ設定やりたいです、すぐやっていいですか
- だめです、各チームから承認とって各チームにやってもらってください
- DMMの目指す開発像として
開発者にセキュリティチェックしてもらうがあった - 技術選定
- LandingZone
- 組織マスター
- セキュリティ
- ログアーカイブ
- LandingZone
- 監視体制
- チームごとにSlackチャンネルを作って、アラートを飛ばす
- セキュリティチームは全チャンネルに参加
- 利用サービス
- Config Rules、Cloud Trailなどたくさん
- Config Rulesについて
- なんでSecurityHubを使わないの？
- 難しいアラートを除いて最低限のものだけを選定したから
- アラート管理のための技術選定（AWS外）
- 方針
- 開発者にセキュリティをやってもらう
- 使うツール
- Slack（コミュニケーションツール）
- Jira（チケット管理ツール）
- SlackbotでSlackとJiraを連携
- 方針
- DMMのチームをめぐり承認をもらう旅
- 開発者にやってもらうための「お金」、「承認」をもらう旅
- 各チームをどさ回り
- 結果
- 80チームから承認
- 300アカウントのセキュリティ設定完了
- 50アカウントの削除
- やって一番よかった結果かも
- アラート状況
- 4500箇所をチェックし、3200個の最終チェックが完了
- やばい設定不備
- DBパブリック公開：20件
- S3書き込み権限のパブリック公開：6件
- 実際起きてた事故（SecurityHubで発見）
- 3件！！
- ここまでの道のりをまとめたスライドはこちら
- AWSセキュリティガードレールとは？
- 第2話：ガードレールを支える技術
- 管理者の運用の話
- Orginizations OU
- 80あるのでどのアカウントに入れるのかわからない
- OU名にSlackチャンネルIDを入れて対処している（未解決）
- SlackIDやOU名で検索できないので不便
- サービスマネージド型CloudFormationStackSets
- 管理者権限でメンバーアカウントへ設定するためのCFnStackSet
- 自動デプロイが便利なので寄せたい
- でも寄せきれていない
- グローバルリソースとリージョナルリソースに依存関係
- Chatbot（グローバル）
- Event Bridge（リージョン）
- SNS（リージョン）
- 解決してない！
- アカウント毎の例外設定
- 例外覚えてられない
- 解決策=すべてCI/CDに寄せてコード化
- 組織変更が多すぎてその度にアカウントを移動させている
- CI/CD
- OUが80あるのでテンプレート更新のたびに80回StackSetを実行している
- 手動アップデートが辛い
- 解決してない！
- 第3話：開発者がセキュリティチェックする文化
- ガードレールの要件
- 開発者にやってほしい
- 結果=みなさん結構やってくれてる！
- チケット状況を見てもなかなか健闘
- やってくれているからこそ議論が発生する箇所
- Webサービスだし、80,443portの解放は当たり前だろ！
- サービスリリースしてからやろうよ！
- 議論を生むこの状況は大歓迎
- LandingZone構築のその先
- 構築まではどこも同じ
- その先が各社異なる
- DMMでは開発者にやってもらう
- 1年PJやって、作ったのはLanding Zoneではなく、開発者がセキュリティチェックする文化だったと気づいた
- ガードレールの要件
- まとめ
- ガードレールを敷けた
- 設定不備・セキュリティ侵害を発見できた
- 開発者が自発的にチェック
- AWSレイヤーのセキュリティ自給率が高まった
- ガードレールを敷けた
- 質問：承認されたアカウント数は80だったが承認されなかったチームはあるのか
- あります。
- 自分たちでやります！というチーム、別の理由でできなかったチーム
感想
ガードレールを構築する過程で全チームを渡り歩くどさ回りをされていて、セキュリティを始めるということの大変さを追体験できました。
結果、不要なアカウント削除ができたり、まじでやばい設定不備やセキュリティ事故を検知&改善できていて、よかったな、と。
そして、開発者が自分でセキュリティをチェックする文化is素晴らしい
Session５：助けてください、セキュリティどうすればいいですか 株式会社ゲオホールディングス 竹内 誠さん
- ゲオの情シスどんなところ？
- 社内で使うシステムの開発運用保守
- レンタル汎用システムは元々なかったので、内製でつくる文化がある
- コンシューマ向けは別部署
- 社内で使うシステムの開発運用保守
- セキュリティお願いします
- 今年に入って、セキュリティ大丈夫？と偉い人から。
- 大丈夫じゃないです！（正直）
- 強化お願いします。
- 取り組み状況
- 基本は境界防御とエンドポイント、海外はSASE
- AWS、Azuleを使っているのでCSPMで見える化
- やったこと
- ひたすらググる
- 何を守るか、CSIRTなどを知識をつけた
- ベンダーに相談
- いろいろ提案されるが、料金の幅があり難しい
- アセスメントの実施
- 組織面が弱いことを指摘される
- ひたすらググる
- 困っていること
- 進め方と方向性が合っているかわからない
- CSIRT立ち上げ
- 情報資産棚卸し
- SOCチーム立ち上げ
- など
- 質疑応答的相談
- 臼田さん
- 何もできていない状況からここまでもってきたのはすごい
- 対応方針は間違っていない
- アセスメントがとてもよかった
- アセスメントにお金かけられるか？が最初の壁
- 対応の順序も適切
- うまくいった秘訣は政治的なところにしがらみがなかったこと（竹内さん）
- 吉江さん
- なんでセキュリティの話になった？
- なんで急にセキュリティについて聞かれたかわからない、唐突（竹内さん）
- 元々セキュリティについてはワードレベルでは知識があった（竹内さん）
- 進め方があっているか？の判断としてお尻が決まっているか？がある
- SOCチームと別のチームの立ち上げ
- インシデントハンドリングを行う情報セキュリティチーム
- 情報アセットマネジメントを担うチーム
- 社内リソースでできるか確認中だが、外部委託も検討中、いズレは社内リソースでやりたい（竹内さん）
- なんでセキュリティの話になった？
- 大竹さん
- メンバーはその気になっているか？
- 自社1人+協力会社1人+ベンダーの体制でやっている（竹内さん）
- メンバーはその気になっているか？
- 吉田さん
- 情報資産の棚卸しをやっているのは偉いが、一歩先の流通経路の制御にも目を向けるといい
- 情報資産の棚卸しはこれからやるところ（竹内さん）
- 難しい話ではなく、まずはISMSやISOのようなところで使われるものの拡張として考えるのがリーズナブル
- 情報資産の棚卸しをやっているのは偉いが、一歩先の流通経路の制御にも目を向けるといい
- 臼田さん
- AWSリソース管理について
- 課題
- 開発環境はセキュリティ緩めに作っているので、よくアラートが上がる
- 開発者にアラート対応してもらうという話を聞いたので、明日からやってみる
- 本番環境はインフラチームが作業しているのでボトルネックに、IaCの導入を進めている
- 開発環境はセキュリティ緩めに作っているので、よくアラートが上がる
- 質疑応答的相談
- 臼田さん
- 開発者の方にうまくやってもらう仕組みをつくることが大事
- DMMさんの例のようにあまりアラートを見せないようにする、など
- どんなアラートが上がる？
- SG周りのアラート（竹内さん）
- 本来はガイドラインの整備と一緒にやるもの
- なんでそうするのか？どうするのがより良いのか？を根拠付きで出すと取り組みやすい
- セキュリティの問題を手前に持ってくることも大切
- 吉江さん
- ガイドラインがないならFAQを作っていくのもいい
- DMMさんの例のJiraのようなツールを使うと対応内容のノウハウ化が楽
- Highはすぐやる、Middleは少し後でいいなどのルール作り
- 吉田さん
- やってはいけないアクションはあらかじめ縛っておく、やり方
- CloudTrailの無効化など
- アラート疲れの問題
- IaCでセキュリティを担保すればアラートが出づらくなる
- IaC導入がいつ終わるのか
- 導入は終わりなき旅
- 小さいところから始めていくことが良い
- すべてIaCはなかなかきつい
- やってはいけないアクションはあらかじめ縛っておく、やり方
- 大竹さん
- アラート発砲の経緯って追えていますか？
- 試行錯誤によるものだったらいいが、とりあえず開けているかも（竹内さん）
- 開発者ーSOC間で摩擦が起きないようにサンドボックス環境を作って、そこで慣らす
- サンドボックス環境はやられる前提でルール整備するのが良いかも
- アラート発砲の経緯って追えていますか？
- 臼田さん
- 課題
- 進め方と方向性が合っているかわからない
- Sli.doからの質問
- 質問：進めていくしがらみとか、2人でやるのは辛くないか
- トップダウンの依頼なのでしがらみはない
- 人は欲しいが、セキュリティ人材が集められるとは思っていない
- やる気のある人が来てくれたら嬉しい
- 質問：セキュリティは〜〜をしたら大丈夫、ってものではないが、偉い人への報告はどうする？
- セキュリティ防御のサイクルができたら報告可能
- インシデントを受ける、何を守るのか？の定期的なチェック
- 外部からの攻撃を受けて、対応するの一連の流れ
- 仲間を増やすアプローチができたらいいな（吉江さん）
- 全部署横断的なタスクフォースはできないかな（大竹さん）
- 期間限定で他チームからSOCチームに来てもらう（吉田さん）
- セキュリティ防御のサイクルができたら報告可能
- 質問：パネラーに質問、組織にセキュリティ担当は何人くらいいるもの？
- 5人中1人いたら御の字（吉江さん）
- 専任が難しい場合、兼任か兼任をローテーションすることが現実的（吉田さん）
- 質問：進めていくしがらみとか、2人でやるのは辛くないか
感想
現在進行形で困っている登壇者を、運営メンバーがアドバイスするという一風変わったセッションだった。
困っている、とのことだがどうすればいいのかわからない、というわけではなく、アセスメントの実施やチームの立ち上げなど、進められるところはしっかり進められていて、勉強になった。
次回以降のSecurity-JAWSでセキュリティ施策の進行状況を聞くことができることを楽しみしています。
最後に
今回のSecurity-JAWSではどのセッションでも濃密なお話が聞けました。
周りの会社様がセキュリティで頑張っている話を聞くと、うちでも頑張らなきゃ、となる方はいるんじゃないでしょうか？
私はAWSのセキュリティについてわからないことばかりなのですが、どんどん学んでいきたいなとモチベーションにつながった気がします。
ではまた、東京オフィスの芦沢でした。
4
