Security-JAWS 第32回レポート #secjaws #secjaws32 #jawsug #サイバーセキュリティは全員参加
Security-JAWS 第32回のレポートです。盛りだくさん過ぎましたね。mini Security-JAWSを開始するのでぜひ参加してください！
2024.02.14こんにちは、臼田です。
Security JAWS 第32回が開催されましたのでレポート致します。
Security-JAWS【第32回】 勉強会 2024年2月14日(水) - Security-JAWS | Doorkeeper
動画
レポート
Session1: サイバーセキュリティ戦略 自由、公正かつ安全なサイバー空間に向けて 内閣サイバーセキュリティセンター 長谷川 智美さん
- サイバーセキュリティ月間の告知をします
- 今年も2/1からサイバーセキュリティ月間が開催されている
- ハッシュタグは
#サイバーセキュリティは全員参加 - サイバーセキュリティ月間は国で定められたもの
- サイバーセキュリティ基本法で定められている
- サイバーセキュリティ戦略の普及啓発を強化するプログラムの中にある
- 施策ごとにターゲットが決まっている
- 普及啓発主体が連携して働きかける
- 啓発やモラル教育など
- 普及啓発主体が共通して利用できる取り組みがある
- 今年のサイバーセキュリティ月間はタレントの王林さんを起用している
- キックオフイベントを2/1に開催した
- 近年のサイバーリスク
- 個人にはフィッシングやサポート詐欺
- フィッシングは過去最多の80億円の被害額
- 情報セキュリティ10大脅威にも取り上げられている
- 今年はフィッシングやサポート詐欺を学べる動画コンテンツを公開している
- 企業はランサムウェアが問題
- 被害金額は中小企業のほうが大きい
- 経営層の意識がセキュリティに向くことが大切
- 経営層向けのセミナーもやる
- 3/14に実施
- 昨年の名古屋港の事例などがある
- オンラインでも会場参加もある
- 個人にはフィッシングやサポート詐欺
- サイバーセキュリティを支える人々というコラムをやっている
- 今年は人材育成をテーマにしている
- 業務内容やセキュリティの魅力などを語ってもらっている
- 皆様にお願い
- 様々な人や組織にセキュリティの重要性を伝えてほしい
- ぜひみなさんの発信力を貸してください
Session2: 新しい初心者向けのSecurity-JAWSをやるよ！って話 Security-JAWS 臼田
- 初心者向けのSecurity-JAWSイベントやります！
- 早速2つ公開していますのでぜひ、定常的に手を動かして勉強したい方はエントリーしてください！
Session3: [韓国版] AWSセキュリティのベストプラクティスに関する利用実態調査のレポート完成報告 Security-JAWS ひろかず
- あの、昨年実施した、AWSセキュリティのベストプラクティスに関する利用実態調査を、韓国向けに実施したレポートが、完成しました！
- この調査は、AWSのセキュリティベストプラクティスって実際どれくらいできているの？っていう質問をAWS利用者にとってまとめたものです
- 今回は韓国の方にヒアリングして、日本と違った状況があるのかなどを確認しました
- レポートは110ページの大ボリューム
- 30の設問を複数の観点で分析した
- 16の分析結果を掲載した
- 押しポイント
- 継続的なリスク評価とデータの重要性定義について素晴らしい結果があった
- 組織内の役割でベストプラクティスをキャッチアップしている人は誰か、インシデント対応の事前準備の項目
- AWS公式ドキュメントには日韓の違いが見える
- 説明責任について
- レポートはこちら
Session4: AWS re:Invent 2023 Security re:Cap アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 佐藤 航大さん
- 昨年のre:Invent2023についてのre:Cap
- イベント概要
- AWSによるクラウドコンピューティングに関する世界最大規模の学習型カンファレンス
- 2023/11/27 - 12/01
- 5テーマの基調講演、2000以上のブレイクアウトセッション
- 現地参加は50,000人
- 日本からは1,700人以上
- Steve Schmidtのセキュリティの話
- セキュリティ領域でAIをどのように活用していくべきか
- セキュリティは人の課題
- 技術的な話題に行きがちだけど、データを欲しい人や金銭が欲しい人が背景にいる
- 防御も攻撃者を想定して検討したり、限られたリソースをどうするか人が検討する
- セキュリティはチェスのようだ
- 効果的にリソースを使う必要があり、AIもその一部
- 論理ベースや機械学習などの技術を使ってセキュリティを強化するツールがある
- 生成AIを活用するとコンテキストを理解した上で対処できる
- 既存の仕組みに組み合わせて生成AIも活用できる
- しかし、生成AIは非決定的なので、アウトプットは必ずしも正解ではない
- 効率化はできるが、判断をするのは人で有り続ける
- サービスアップデート
- いっぱいある
- 資料は後ほど共有されるので詳細はそちらで確認してください
- 生成AIについてをピックアップする
- Amazon Inspector
- 脆弱性管理のサービス
- ネットワーク露出も確認できる
- 今回コードスキャンに生成AIを使ったアシスト付きコード修正が追加
- Lambdaコードスキャンで検出した脆弱性について修正コードを提示してくれるようになった
- 脆弱性対応が効率化できる
- マネジメントコンソールではコードのdiffがハイライトされてよく分かる表示になっている
- Amazon Detective
- 検出した脅威の調査ができる
- 今回生成AIによる検出結果グループのサマリーを出せるようになった
- 自然言語で要約して表示してくれる
- AWS Config
- AWSサービスの構成をチェックできる
- 今回自然言語クエリプロセッサが利用可能になった
- リソースの設定やコンプライアンス状況をSQLで照会する高度なクエリのクエリを自然言語で作ってくれる
- SQLの経験があまりなくても利用しやすくなった
- 発見的統制のアップデート
- AWS Security Hub
- セキュリティの検出結果を集約する
- セキュリティ標準のチェックをしてくれる
- 今回コントロールのカスタマイズができるようになった
- チェックするルールの細かいパラメータを調整できるようになった
- 例えばログの保持期間をより長い期間に設定するとかできる
- 今回管理者からの一括設定をサポート
- AWS Organizationsの管理者アカウントからセキュリティ基準とコントロールを一元的に管理することができる
- どの標準やコントロールを利用するか制御できる
- Amazon Inspector
- 今回EC2インスタンスのエージェントレス診断ができるようになった
- これまではSSMエージェントが必要だった
- EBSスナップショットからチェックする仕組みが使えるようになった
- 今回EC2インスタンスのエージェントレス診断ができるようになった
- AWS Security Hub
- まとめ
- 新サービスはなかったが地に足がついたアップデートが多かった
- 宣伝
- AWS Security and Risk Management Forumが3/19にある
- AWS re:Inforce 6/10-12にある
感想
いろいろ嬉しいですね。Security Hubの一括管理ちょーうれしー！！！
Session5: 生成 AI のセキュリティと生産性を両立させる アマゾンウェブサービスジャパン合同会社 Machine Learning Developer Relations Takahiro Kuboさん
- 機械学習をプロダクトに活かすためのワークショップをGitHubで公開している
- 生成AIへの期待とリスク
- 生成AIは新規ビジネスの創出や業務効率化、顧客との関係にインパクトをもたらす技術
- しかしリスクと課題もある
- 信憑性のリスク
- 悪意ある、差別的な生成のリスク
- 知的財産権のリスク
- 秘密保持のリスク
- 信憑性のリスク
- 例えば脆弱性の情報を聞いてもでたらめな内容が返ってくることがある
- これはハルシネーションという
- 悪意ある、差別的な生成のリスク
- Vimを使う人はどんな人ですか？と聞くと差別的な回答になることがある
- 知的財産権のリスク
- コントロールされていない素の基盤のリスク
- 秘密保持のリスク
- 他者のプロンプトから学習した情報が流出する可能性がある
- 責任あるAI利用にはリスク以外にも課題がある
- 制御性
- プライバシー
- 安全性
- 公平さ
- 信ぴょう性
- 説明可能性
- 透明性
- 統治
- 責任共有モデルに基づくリスクへの対応方法
- 責任あるAIをモデルの開発から利用までプロセス全体で実現する
- 責任共有モデルによる分担
- AWSとしては基盤モデルを提供
- 責任あるAIのサービス提供をする
- じゃあAWSのモデルは安全なの？
- 研究
- 論文の公開をしている
- 論理から実践
- AIサービスカードを出して透明性のある情報を公開している
- 安全な学習データ
- Titan FMは顧客のデータから有害なコンテンツを検出削除して出力のフィルタリングもしている
- 利用規約で知的財産権侵害請求に対する弁護と補償がある
- ガバナンス
- ベストプラクティスを踏襲している
- アノテーターの教育と多様性を重視している
- ユースケース固有のリスクを評価する(金融・医療等)
- 研究
- ステークホルダの巻き込み
- 規制や標準化への取り組みに参加している
- ホワイトハウスやAIコミュニティなど
- 社内外からの攻撃の検証をしたりしている
- 利用者がどうやって安全に利用できるか
- 当たり前のセキュリティ機能はある
- ネットワークのアクセス制御や暗号化
- Fine Tuningのデータは暗号化、お客様専用にコピーして学習、本体のモデルの学習には利用されない
- 300を超えるセキュリティサービスと機能を提供
- 画像生成AIの例
- API Gatewayが受け取る
- Comprehendが安全かチェック
- モデルを生成
- 有害なものが出力されたらRekognitionのModerationチェック
- でも作るのは手間だよね
- Guardrails for Amazon Bedrockをリリース
- 上記の例の実装と同じような機能がマネージドである
- 例えば投資や医療の質問は回答しないようにする
- フィルタの強度をゲージで調整できる
- Model Evaluation On Amazon Bedrock
- モデルの評価ができる
- 予め用意された分類のデータセットや持ち込みデータセットに対する精度や有害性、プロンプト変更への耐性をチェックできる
- Amazon CodeWhispererでも出力の評価が行われている
- コードの生成素が安全か確認したりできる
- まとめ
- 生成AIのセキュリティと生産性を両立させるには
- 新しいリスクと課題を識別する
- リスクを低減し、課題解決につながるAWSのサービスを選択
- 生成AIのセキュリティと生産性を両立させるには
感想
AWSの責任あるAIの考え方は参考になりますね。ビジネス判断においては生成AIはうまく採用していきたいところですから、AWSの出してくれる仕組みはどんどん活用しましょう！
Session6: IaCでセキュリティを強化しよう！～ IAMが苦手な開発者でも簡単に権限を絞れる。そう、AWS CDKならね！ ～ みずほリサーチ&テクノロジーズ株式会社 プロジェクト推進部 (兼) 先端技術研究部 松尾 優成さん
- 社内向けAWS共通プラットフォームの紹介
- 社員が安心してAWS環境を利用できるようにするプラットフォーム
- Control Towerを利用している
- 話すこと
- セキュリティ観点でAWS CDKの良いところ
- 実際に使っているプラットフォームの設定例をコードで紹介
- IaCの概念やCDK利用するための話はしない
- こんな悩みはありませんか？
- IAMポリシーやS3バケットポリシー大変じゃないですか？
- CDKのメリットを伝えます
- AWS CDKとは
- 開発者体験に優れたOSSのIaCツール
- アプリもインフラも使い慣れたプログラミング言語で構築可
- ベストプラクティスに沿った抽象化されたライブラリ(コンストラクト)を使うと簡単
- 学習コンテンツが豊富
- ワークショップやBlackBeltがオススメ
- 今年はIaCのアップデートが熱い
- 飛び込みやすくなっています
- 本題のセキュリティ観点でのメリット4つ紹介
- ポリシー関連の設定が抽象化されていて簡単
- S3のRead権限のCFn例
- 実際のポリシーと同じよな記述で認知負荷が高い
- CDKなら3行で書ける
- grantReadを使うと簡単に権限を渡せる
- リソースベースポリシーも簡単に書ける
- 組織IDを引数に入れると、40行ぐらいあるバケットポリシーも作れちゃう
- SSLを強制するポリシーも1行
- KMSの権限とかも簡単
- grantDecript
- ベストプラクティスに沿ってgrantを積極的に使おう
- S3のRead権限のCFn例
- モジュール化と単体テスト
- CFnだと同様のセキュリティ設定が羅列されやすい
- 必要なプロパティをすべてのリソースで記述したりする
- たくさん同じだと修正漏れとかもある
- CDKは独自のコンストラクトを作成して共通化できる
- 単体テストでチェックもできる
- テスト済みなら繰り返し処理を安全に利用できる
- CFnだと同様のセキュリティ設定が羅列されやすい
- カスタムリソース
- CFnサポート外のリソースもある
- カスタムリソースはLambda不要で簡単に利用できる
- Service Catalogポートフォリオの関連付けに使っている
- リソースの細かい設定もできて最小権限しやすい
- cdk-nag
- セキュリティ・コンプライアンスチェックツール
- デプロイを強制的に停止とかできる
- 様々なルールやそれらをまとめたマネージドのパックあり
- 単体テストでcdk-nagを使うと早期に違反を検知できる！
- 単体テストのTipsはこちら
- integ-tests
- 実環境に一時的なリソースをデプロイして統合テストを行う
- TTPやAWS API、Lambda実行などで期待通りに動くか確認
- 正常系、異常系のアクセステストを自動化できる
- 検証結果
- テスト実行時間が約25分
- コードレスなAWS APIのメソッドでは正常アクセスのみ確認可
- Access Deniedを確認したい場合はLambda関数が必要
- 所感
- アクセステストに限定せずデータ入出力に着目した正常処理の一環で権限確認するのがよさそう
- 各種ポリシーが固まっていない状況ならデプロイして手動テストしたほうがよさそう
- ポリシー関連の設定が抽象化されていて簡単
- まとめ
- AWS CDKは便利！ぜひ使ってみよう！
感想
CDKはいいぞ！まずgrantを体験しよう！
Session7: IAM policyをOrganizations SCPに移行した話 アクセンチュア 中野 沙耶さん
- 発表の目的とお断り
- IAMをSCPに移行する方へのナレッジ共有が目的
- サービスの説明などは割愛します
- SCP移行の背景
- Organizationsを利用できない契約のアカウントを複数管理
- Denyリスト方式で操作制限を行っていた
- 操作できないIAM Userの作成などは管理者が行うようにしていた
- DenyリストではActionを細かく指定し、permissions boundaryを含む複数のIAM Policyで構成していた
- アカウントが増えていったので統制を横展開していったりした
- 移行前の課題
- 管理していくアカウントが増えるたびにデプロイ作業が発生していた
- IaCはしていたがそれなりに工数はかかっていた
- 適用するポリシーが多く、設定ミスのリスクがあった
- 利用者の作成したIAM Roleに操作制限を適用できてなかった
- Organizations利用開始
- 契約形態を変更した
- アカウントの払い出し手順などを変更した
- CloudFormationのStackSetsで払い出した
- 課題の一部が解決した
- 移行の狙い
- さらにOrganizationsを活用するためにSCPに置き換えしたくなった
- 残りの課題も解決したかった
- 移行のためにやったこと
- Conditionに色々追記するため、IAMポリシーの軽量化をしてSCPに切り替えた
- テストをして意図しないものがないか確認
- SCPを実際に作成してテスト
- 移行手順と運用手順を更新して移行開始
- つまづきポイント
- SCP作成
- すべてのエンティティに適用されるので管理者は適用外とするConditionを設定した
- 利用者がCDKを使う場合もあり、管理側でもCDKを利用するため、管理者用のRoleを利用するようにCDKのQualifierをカスタマイズした
- SCPはルートユーザーにも適用されるため適用外にした
- SCPの構文でAction要素でワイルドカードは末尾にしか使えない、NotResource要素が使えないのでIAM側に一部残した
- SCP構成検討
- SCPは1つのOUに5つまでしか適用できない
- 親子で継承はできる
- デフォルトでFullAWSAccessのSCPも必要なため実質4SCPまで
- テスト
- Policy Simulatorで検証しようとしたが、SCPのCondition要素は考慮されなかったので境界値テストを実際に操作した
- 運用手順更新
- 権限エラーが生じた場合の確認スコープに管理アカウントのSCPも確認する運用とした
- SCP作成
- 移行結果
- 大半の課題が解決できたが一部残った
- ポリシー適用は簡素化したが、引き続き設定ミスのリスクは残っている
- まとめ
- SCPではNotResource要素がサポートされないので気をつける
- ポリシーサイズや数は気をつける
感想
SCP使うときのハマりポイントがいろいろまとまっていますね。結構ハマりやすいのでぜひキャッチアップしましょう！
Session8: 時間切れで書き切れなかったOCSFの行く末とは 日比野 恒さん
- 普段はログにまつわることをやっている
- 今日はAWS Security Lakeの話をしていく
- 最適なログ基盤のアーキテクチャとは
- このツール使えば最強だよ、というものはない
- どんなスキルの人がログを使って何がしたいかによる
- 各自のやりたいことや実現したいことに応じて最適なツールやアーキテクチャにたどり着けるようなものが必要だと考えAWS継続的セキュリティ実践ガイドを書いた
- 執筆時にあったこと
- 執筆している途中でAWS Security LakeがGAしちゃった
- 執筆完了したあとにもいろいろ関連アップデートがあったのでOSCFについては本に書ききれなかった
- 余談ですがAWSではじめるクラウドセキュリティの本を先に読むといいよ
- Security Lakeとは
- セキュリティで利用するログやイベントをあとで活用しやすい形式でS3に集約するためのサービス
- フォーマットがOCSF(Apache Parquet形式で保存)
- AWSがソースのものと、サードパーティがソースのものも扱う
- ログはAthenaでクエリしたりDetectiveから利用したりできる
- 思想というか制約というか
- AWSセキュリティリファレンスアーキテクチャに準拠している
- AWS Organizationsの管理下で使う必要がある
- 検証環境構築のハードルは意外と高い
- 現時点では未対応なAWSサービスのログがある
- セキュリティじゃないログ系など
- OCSFの話
- Open Cybersecurity Schema Framework
- Splunkはじめいろんなベンダーが構築している
- 6つのカテゴリ、32種類のクラスに分類される
- それぞれスキーマの定義がある
- CloudTrail監査ログは3005など、決まっている
- Trailのスキーマ構造
- いろいろstructのところがあるのでパースが大変
- unmappedにjsonが入っている
- マッピングできなかったものが入る
- 柔軟性のための場所
- これもパースが大変
- Athenaでクエリする場合
- 抽出や時刻変換が必要
- MAPはMAP_FILTERを利用する必要があるので大変
- unixtimeはミリ秒まで入っているので/1000してからキャスト
- OpenSearch Serviceに取り込んでみた
- 取り込み方が2つある
- SIEM on Amazon OpenSearch Serviceで取り込んだら大体パースしてくれるがunmappedは構造体のまま入ってくる
- 共通のスキーマ定義といっても結局構造を見ていく必要がある
- どのように向き合うといいか
- Security Lakeを利用する上での考え方
- 使い方
- どんなデータがあるか探索的分析をする
- インシデントが発生したときになどに使う
- トレンドを確認したりするなど可視化する
- リアルタイム性のあるアラートを上げるなどの監視
- どんなデータがあるか探索的分析をする
- 使い方によってデータの取り方が違う
- Security Lakeではサブスクライバーを使って取りに行ける、探索的分析ならそれでいい
- リアルタイム性が求められるなら直接データを取りに行く必要がある
- 使い方
- Security Lake vs S3
- つよみとつらみをまとめている
- 詳しくはスライドで
- Security Lakeを利用する上での考え方
- まとめ
- 良いところもあるが課題もある
- まだサードパーティは直接取り込んだほうが良さそう
- 今後のアップデートに期待したい
- 良いところもあるが課題もある
感想
Security Lakeが出てきてログのフォーマットを整えてまとめられるようになりましたが、どう使うかに合わせて選択する必要がありますね。
Session9: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー
[Yuki.S]・ペネトレーションテスト（侵入テスト）をAWSで実施した後の対策などはどうしてるかきになります！
- ペネトレーションテストで出てきた項目を単純に治すだけではなく、それを作り込まないように運用していきましょう！
[Anonymous]・将来的にAWS＋セキュリティの二軸でキャリアを積んでいきたいと考えているのですが、そのなかで「この本はぜひ読んどけ！」というものがあれば是非教えていただきたいです。
[メルク]・セキュリティの知識が全くありません。また、これまでWebアプリをローカルでしか作ったことがありません。ECRとApp Runnerを使って、JavascriptとPythonのFlaskのWebアプリを作ります。利用者は許可した人だけが使えるようにします。導入すべきセキュリティ対策を詳しく教えてください。
- まず徳丸本を読みましょう
- その上でSecurity for Developersで勉強するといい
[Anonymous]・初めてAWS WAFを導入する時、みなさんはどのように適用するWAFのマネージドルールを決めていますか？選定のコツ、考え方のアドバイスをいただきたいです。
- まずはドキュメントを読みましょう
- すると自分たちの環境に適用すべきか理解できるはず
Session10: 2023年(度)のSecurity-JAWS総括 Security-JAWS 吉江 瞬
2023年度はたくさんの活動をしました。2024年もやっていくぞい！
さいごに
盛りだくさん過ぎましたね…
アーカイブ動画も上がりますので要チェックです！
mini Security-JAWSもぜひエントリーしてください！
