Security-JAWS 第35回レポート #secjaws #secjaws35 #jawsug

Security-JAWS 第35回のレポートです。

#JAWS-UG

#セキュリティ

#レポート

#AWS

臼田佳祐

2024.11.18

こんにちは、臼田です。
Security JAWS 第35回が開催されましたのでレポート致します。
Security-JAWS【第35回】 勉強会 2024年11月18日(月) - connpass
ちなみに前回から、Connpassを利用しています。今後はConnpass中心となりますので、ぜひSecurity-JAWSのページからメンバー登録いただけると助かります。
 動画https://www.youtube.com/live/FNwtFDgLF3U
 レポート Session1: クリティカルなシステムの運用を AWS Incident Detection and Response で強化する	アマゾンウェブサービスジャパン 技術支援本部 庄司哲也さん普段は事業開発としてAWSサポートを担当している
ぬくもりを持って提供している
技術者ではないのでお手柔らかに

AWSサポートの全体像
大きく分けるとサポートプラント有償オプションの2つ
サポートプランはベーシック・開発・ビジネス・エンタープライス On-Ramp・エンタープライズ
有償オプションにCountdown Premium・re:post Private・IDR
ここ最近で色々増えた
お客様のサポートに求める要件が変わってきた
幅広く支援させてもらっている


サポートプラン
ベーシックは技術的なサポートは無し
開発者から技術的なサポートがある
ただし平日9-18時対応

ビジネスだと24365
本番ワークロード向けの基本的なプラン
日本語を話すエンジニアが最短1時間で初回応答
お客様のユースケースを踏まえたアーキテクチャガイダンス
コンテキストに応じた支援ができる

Trusted Advisorなど便利機能が利用できる

エンタープライズはミッションクリティカルなワークロード向け
TAMによる支援がある
On-Rampだとチーム支援になる


サポートを使うときのポイント
技術的なお問い合わせに関するガイドライン
正しい問い合わせ方法を理解するのが大事
タイトルに緊急度を入れても反映されない
プルダウンで選びましょう

問題が今起きているのかどうかを書く
リソースを具体的に明記する
などなど

最近Slackアプリでサポート連携できるようになった
AWS Support Slack のアプリ - AWS Support
普段Slackを使っているならより使いやすい


AWS Incident Detection and Response(IDR)
ここでいうインシデントはセキュリティのインシデントではない
アベイラビリティ(可用性)のインシデントが対象
もちろんDDoSなどがあればアベイラビリティにも影響があるので対応する
アベイラビリティと関係ないセキュリティのインシデントはスコープ外

お客様の声
エンドカスタマーからの深刻が来て初めて障害に気づいた
問題箇所の特定を素早くしたい

IDRとは
お客様システムに障害が発生した際に、AWSがプロアクティブに初動対応を行うことで早期復旧を支援するサービス
AWSのインシデントマネージャーが対応を開始する
どうやるのか？
インシデントマネージャーが24365でお客様システムのアラームをモニタリングしている
インシデントマネージャーがアラームにお客様と同時に気づく
一緒に対応していく
5分以内で応答する



Accelerated recovery path
従来だと障害が発生したら検知して、お客様自身で確認してAWSへの問い合わせ
エンタープライズプランで15分以内にAWSが初回応答する

IDRだと障害発生時すぐにAWSが気づきお客様に連絡
Web会議にすぐに入って会話できる状態になる
調査も並列で行われる


詳細な仕組み
お客様側でオブザーバビリティの仕組みがある状態から始まる
アラームの中から特に重要なものだけ選定して、EventBridgeを経由して通知してもらう
インシデントマネージャーがアラートを受け取ったらお客様固有のランブックを見ながら対応
ランブックにはお客様のビジネスやアーキテクチャなどが書かれているのでそれを使って対処を開始する
どのアラームで誰に連絡するかなども書いてある
アラームの要件の設定とランブックの作り込みをサービスのオンボーディングをしていく

IDRをどうやって活用するか
日頃からインシデント対応の体制を整える
たとえばオンボーディングの中では誰に連絡するか、連絡がつかないなら何分後に誰に連絡するかなどを詰める

アラームの設計も重要
アラームがたくさんあったりオンプレのままで見直しできていない、とかの課題もある

アラームについてはIDRのチームがベストプラクティスを公開している
Lambda - Incident Detection and Response Alarming Best Practices | AWS re:Post

 感想セキュリティインシデントはスコープ外ですが、可用性も大事な守っていくポイントですね。
よりミッションクリティカルな環境では参考になりますし、そうでなくても考え方は参考になりますのでサービスを正常に運用するための参考にしましょう！
 Session2: コンテキスト重視のCNAPP	Tenable Network Security 株式会社 Masa Itoさんアジェンダ
CNAPPまわりの話
話さないこと
営業目的の話

ゴール
CNAPPとはどんなものかをザクッと理解いただく


CNAPPまわりで話題になったこと
Google親会社のアルファベットがWizを買収するニュースになった
結果拒絶した
CNAAPPという領域が注目を集めている

CNAPPとかCTEM
いろんな用語がある
Continuous Threat Exposure Management
継続的にシステムやデータのセキュリティリスクを評価し管理するためのアプローチ

CNAPP
クラウドネイティブアプリケーションを保護するための領域

今回はCNAPP部分を話す

CNAPPは一括りにはできない
クラウドで動いているアプリケーションもいろいろある
いろんな言語のソースコードもあります
そこを保護するのはSAST/DAST/IAST/RASPなど

OSSもたくさん使っているのでチェックする
SCA/SBOM

IaCに対してもスキャンする
VM/Containerにはワークロード保護やimageスキャン
インフラにCSPMなど
CNAPPはいろんなレイヤーを見る
上の方は最近はASPMと言ったりもする
シフトレフト/DevSecOps系

上の方は開発者側で下の方はオペレーションになったりする
Tenableはインフラ寄りの方を見る

コンテキストが重要
CWPで脆弱性を検出して、実際にどれくらい公開されているか・設定ミスはあるかという状態と掛け合わせてリスクを判断する
CIEMで高い権限の管理もする

実際のCNAPP
いろんなクラウドが見れる
資産の一覧が見れる
いろんな検出が見れる
組み合わさると危ないものが抜粋して出てくる
ネットワークも可視化して表示してくれる
コンテキストを補完して説明してくれる

CNAPPは色んなところを見る
 感想CNAPPと一言で言ってもいろんな領域があるので、各領域についてどうするか検討していかないとですね。
 Session3: クラウドにおけるマルウェアやコンテンツ改ざんへの対策について	佐田 淳史さん事業会社のSecurity Engineerをやっている
IPA10大脅威
1位はランサムウェア
クラウドならではの対策の発信は需要が高いのではないか？

Threat Hunting
既存のセキュリティ対策を回避する脅威を調査してサイバーレジリエンスを向上する

FISCと金融庁のサイバーレジリエンス
事前にリスクをすべて洗い出して対策することは難しい
リスクゼロを追求することは必ずしも合理的ではないというスタンス
リスク属性に応じて対策していくと良い

ランサムウェアの流れ
BlackHatUSAから引用
マルウェアの配布と感染
C2
発見とラテラルムーブメント
データの抽出と改ざん
データの暗号化
恐喝
解決？

AWSからe-bookが提供されている
具体的な方法は解説されていない

具体的にどう取り組めばいいか
account isolation
ADがない環境であれば侵害された影響はアカウント内に閉じる
アカウントを分けることで分離ができる

WORM storage
Write Once Read Manyの略
書き込んだデータを消去・変更できない追記型の記憶方式
バックアップ含めて暗号化されたりするリスクを防止できる
AWSだとS3 Object LockとVault Lock
S3 Object Lock
バケットレベルで有効化できる

AWS Backup Vault Lock
保持ポリシーで各バックアップを削除できなくなる


ECSのRead Onlyマウント
ファイルシステムをRead Onlyでマウントすると改ざんリスクを低減できる
SSM Agentを起動できるようにすることで副作用を防止する


まとめ
保護のための不十分なバックアップは気をつけよう
他にもいろんな対策があるのでそちらもやっていこう

 感想ランサムウェアの対策にバックアップは必須ですね。単純にセキュリティのためだけではなくそもそもBCDRの要件からもバックアップの要件の設計が必要なので、そこから検討していきましょう。
 Session4: VPC Traffic Mirroring と OSS を利用したネットワークフォレンジック基盤の構築・運用	株式会社リクルート 須藤 悠さん好きなAWSのサービスはAWS Organizations
リクルートは21年に統合された
マッチング&ソリューション事業をしている
いろんなサービスを展開している

ネットワークフォレンジック基盤の構成
共通ネットワークフォレンジックの基盤を作っている
Arkimeを使っている
SOCに対してパケット分析環境を提供している
ここでTraffic Monitoringを活用している
M6g.largeを6台でキャプチャ
R6g.largeのOpenSearch
EFSに書き込み

ネットワークフォレンジック基盤の歴史
2019年Traffic Monitoringリリースとともに検討開始
2020年Arkimeを使って提供開始
2021年にはOpenSearch Serviceがでて載せ替え
2024年 52のAWSアカウントに提供

なぜVPC Traffic Mirroringなのか
プロダクトのトラフィック上に障害点が増えないのがメリットで採用した
従来のようにアプライアンスを入れたりGWLBを経由したりすると障害点が増える
プロダクトの障害原因にならないようにする
デメリットとして100%ミラーされることを保証されていない

考慮点
ミラーリングの問題がないかメトリクスを収集している
CWメトリクスから収集してカスタムメトリクスとして集積・モニタリングしている
インスタンスの変更がある
ALBのTargetGroup配下のすべてのインスタンスにMirror Sessionを貼る機能を提供している

制約
ミラー元として利用できるインスタンスタイプが限られる
Fargate非対応
新しいインスタンスは軒並み非対応で最近不便

ミラー元インスタンス内でMTU設定が必要
ヘッダが54bytes追加される
MTUを8947 bytesに設定する


Arkimeの機能上の制約
S3 Writerは大量のトラフィックを裁けないためストレージにEFSを使っている
OpenSearchは利用できるがOpenSearch Serverlessは利用できない

まとめ
メリット・デメリットをよく理解したうえでVPC Traffic Mirroringを利用している
利用するシステム構成に制約がある
Arkimeの実装による制約もある

 感想重厚なフォレンジック環境ですごいですなー

Fargate対応などは欲しい機能ですね！
 Session5: 初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況	臼田 / べこみん解説はそのうちするかも
 Session6: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠	Security-JAWS運営メンバー開発ってあるけど、実はコードを書いたりとかする前に始まっている
組織的な体制やそれが続けられるのかもある
そうでないと場当たり的になる
ガバナンスやオペレーションなどをどうしていくか、というところから始める必要がある
生成AIのセキュリティは幅が広いので通常のシステム開発とも違う
全体像を掴みつつどういう体制でやるかを考えるのが初めでは

どんなことを気にする必要があるのか
原則としては通常のセキュリティと同じ
認証認可やアクセス制御
どんなデータを扱うのか
誰が使うのか
インラインでブロックする機能なども必要

学習の観点
学習させてはいけないものを学習させていないか

CISAも生成AIのガイドもある
フロントのWebアプリは変わらない
コンプライアンスもセキュリティのスコープ
どんな規制要件があるのかはチェックする
出したデータはどう使うのか、プライバシーの観点もある

ほかにもいろいろあったけど一旦以上
詳しくはアーカイブみてね！
 さいごに今回も色々ありましたね！ぜひAWS Securityを勉強していきましょう！