こんにちは、臼田です。
みなさん、AWSのセキュリティ対策してますか？(挨拶
今回は2023年10月12日にオフラインで行われたAWS 国内最大のセキュリティイベントであるAWS Security Forum Japan 2023の下記セッションのレポートです。
リクルートSOCにおけるAWSとの向き合い方
リクルートでは、ユーザーの皆さまの大切な情報をお預かりし、複数のマッチングプラットフォームをサービスとして提供しています。それらの数多くのシステムを外部からのサイバー攻撃や内部不正行為から守るため、日々早期検知と未然防止に取り組んでいるセキュリティ対策の専門チームが「Recruit-CSIRT」。本セッションでは、そんなリクルートのセキュリティ運用部門におけるAWSを活用する側、そして守る側としての両面の立場からの取り組みについてお話しします。
株式会社リクルート スタッフ統括本部 経営管理 セキュリティ統括室 セキュリティオペレーションセンター 商用モニタリンググループグループマネージャー 安東 美穂氏
株式会社リクルート スタッフ統括本部 経営管理 セキュリティ統括室 セキュリティオペレーションセンター 商用モニタリンググループ 柳川 大輝氏
アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 インターネットメディアソリューショングループ シニアソリューションアーキテクト 石本 遼
レポート
- AWSの石本さんから
- 昨今のセキュリティを取り巻く状況の話をした後、リクルートさんのお話
- ビジネスを取り巻く環境の変化とセキュリティ
- 社内ではリモートワーク全盛
- パートナーとも連携する
- 端末やアクセス経路が多様化している
- どのようなデータを取得したり、どのような軸で分析すればいいかが複雑になっている
- サービスを運用する立場として、攻撃が高度になっている
- 組織内部の脅威も検討する
- 俊敏性を保ちつつセキュリティ対策が必要
- セキュリティリスクの考え方
- リスク = 影響 x 発生確率(頻度)
- OWASPによる定義
- ビジネスにどのような影響があるかを考える
- 発生可能性はリスクを生じさせるアクターを特定する
- リスクに応じたガバナンス施策の2つの観点
- 予防的統制
- そのリスクの発生を予防する
- 効果は分かりやすいが業務上の抑制を追加するため俊敏性を抑えることになる
- 発見的統制
- リスクの発生を検知して影響を抑える
- Adminが普段と異なる場所から利用されていることを検知するなど
- 状態や挙動を把握して望ましくないことを捉える
- 予防的統制
- 銀の弾丸は無い
- 一歩ずつ進めていく必要がある
- 予防的統制ですべてのことを打ち取るのは難しい
- ビジネスも阻害される
- クリティカルなことは予防的統制をし、それ以外は発見的統制を入れるとバランスがいい
- リクローと様からの事例
- 多様なサービスや組織規模でどのような体制で取り組み活用しているかという話
- リクルート安東さんの話
- 話すこと
- リクルートのセキュリティに対する考え方
- AWS環境を守る側としてのSOC
- AWSの使い手としてのSOC
- 自己紹介
- エンジニア経験0から商用監視を実施
- リクルートについて
- 1960年創業
- 5万8千人の従業員
- suumo/じゃらん/ゼクシィなど様々なサービスを運営している
- ビジネスモデル
- B to B、B to C、C to Cもある
- リクルートのセキュリティ
- セキュリティマネジメント体制
- リスクマネジメント組織とプロダクト組織がある
- リスクマネジメント組織にセキュリティとうかつとセキュリティ推進がある
- セキュリティ推進部署は各プロダクト組織の情報セキュリティの責任者が兼任している
- AWSのGuardiansに似ている
- カスタマーの個人情報の保護を重視している
- 外部と内部両方を見ている
- セキュリティ対策の考え方の補足
- NISTのCSFをもとにしている
- SOCは検知・回復をメインにしている
- 監視だけではなくペネトレーションテストなどもやる
- 外部連携もする
- 商用環境のセキュリティ監視
- 3つ導入
- IDS / WAF / NWF
- 特にネットワークフォレンジックは他社ではあまりやっていないかも
- アラートは遮断せずにネットワークフォレンジックをして対処する
- 長らくオンプレミスの環境のセキュリティ監視をしていた
- クラウド利用が増えるに連れてAWS環境におけるセキュリティ対策の検討が増えた
- AWS環境を守る側としてのSOC
- 対策の歯やすさや費用対効果がオンプレとはバランスが違う
- SOCのセキュリティ運用はオンプレとクラウドでどう違うか
- オンプレWAFとAWS WAFで比較してみる
- 大きく異なるのはアプライアンスの調達や物理作業がなくなる
- 1時間もあれば設定が完了する
- 監視開始後のライセンス更新などがいらない
- アラート対応では検知後の対応も違う
- オンプレだとリクエストやレスポンスも詳細に確認していく
- AWS WAFではWAFのログでそれらを確認しない
- 基本をブロックに倒している
- 役割が変わったので役割分担が難しくなる
- AWS WAFでも複数の関係者が関わる
- セキュリティ担当者だけでは誤検知か判断が難しい
- リクルートではAWSセキュリティ支援軍という活動を開始した
- セキュリティ要素が混ざった誰も専門としないものを複数の組織で共同支援するようにした
- SOCが旗振りする
- よくある誤検知を社内ポータルで公開するなど
- プロダクトの担当者がWAFの運用に携われるようにした
- AWSの使い手としてのSOC
- 柳川さんから話す
- 担当業務はセキュリティ監視基盤の構築運用やログセキュリティ監視など
- 対策手法・ソリューションの検証
- 脆弱性管理基盤
- ログ分析基盤(Splunk)の話
- これがメインの話
- 2つ運用している
- 1つは社内執務の監視(シンASuLA)
- ADのログや外部持ち出しデータの監視
- もう一つがAWSに展開している環境の監視
- CloudTrailのログなど
- 今回は社内執務環境用のSplunk(シンASuLA)のAWS移行について
- オンプレミス上に複数あったSplunkをAWSに構築して統合した
- AWSに移行して得たメリット
- これまではハードウェア運用の負担が大きく、初期到達のハードウェア以上のスペックが出せず、ステージング環境の確保、リストア・再構築が難しかった
- AWSに移行することで、高い可用性を得ながらハードウェア運用がなくなった
- いつでもリソースを増強できる
- 低コストでステージングを確保できた
- これらのメリットはログ分析基盤にとてもマッチする
- 構築後のログ増加・新規ログ取り込みに対応する仕組み
- 環境構築して終わりではない
- 構築後も設定変更をする
- 本番環境の変更作業は心理的負荷が大きい
- システム影響は無いか
- 設定ミスをしていないか
- これを解決するためにIaCしている
- 本番環境と同じ設定のステージング環境で検証している
- AnsibleとTerraformで設定を管理している
- CodeCommitで管理し、承認者に承認依頼する
- 本番を直接操作することを減らしている
- 3システムを順次移行しながら新規ログ取り込みも成功した
- 注目しているサービス・展望
- 安東さんから
- 先日AWS re:Inforce2023に参加してきました
- AWSのセキュリティに特化した2日間のカンファレンス
- イベントのキャッチアップ以外にもAWSに要望を伝えたりもした
- 2019年よりは大きな規模になっている
- ブースを回ることでトレンドを知ることができる
- 気になったサービス
- Amazon Security Lake
- AWS環境のログを正規化して収集できる
- Amazon EC2 Instance Connect Endpoint
- Amazon Inspector SBOM Export
- Amazon Security Lake
- AWS Security Lakeの活用検討
- Splunkにログを取り込んでみた
- AWS Organizations管理アカウントから管理を委任
- 懸賞アカウントにログを集約
- ログ転送用のSQS/IAMロールを作成
- Splunk Add-on for AWSを導入して取り込み設定
- Add-onはバージョン7以降で対応している
- 所管
- Security Lakeに入れるだけでOCSFに対応するためパース処理が簡素化している
- 新規ログ取り込み時に迅速に分析業務を開始できる
- Splunk運用者以外でもパース処理ができるようになるかも
感想
組織の形としてAWSのGuardiansと同じような取り組みがされているのはいいですね。なかなか実現が難しいと思うのでどういう運用をしているかとか、どうやってその体制を作っていったのかとか詳しく聞きたいですね。
4
