この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第24回が開催されましたのでレポート致します。
Security-JAWS【第24回】 勉強会 2022年2月28日(月) - Security-JAWS | Doorkeeper
動画
レポート
Session1: 2022年サイバーセキュリティ月間 ～#サイバーセキュリティは全員参加～ 内閣サイバーセキュリティセンター（ NISC ）基本戦略第 1 グループ 浦川 隆志さん
- サイバーセキュリティ月間の宣伝
- 今年はマクロスとコラボ
- なんで？
- 今年で40周年
- 幅広い世代に知名度がある
- 男性も女性も、いろんな星の種族の人がいてコンセプトに合っている
- 2022年サイバーセキュリティ月間 - NISC
- 特設ページでいろいろな発信をしている
- 「基本的なセキュリティ対策」や「東京2020大会の対策を振り返る」が新しいコンテンツ
- 基本的なセキュリティ対策ではOSや無線LANルータのアップデートなど、これだけはやっておいてほしいものを厳選して発信
- 一般の方に見てもらいたい
- ご家族や身の回りの方に伝えてほしい
- コラムでは産学官民とつくる・ひろめる・まもるの軸でマトリクスを切っている
- 「東京2020大会の対策を振り返る」では第一線で活躍された関係組織の方々によるコラムを掲載
- 国全体ではまだまだ基本的なセキュリティ対策の実施が十分ではない
- サイバー空間のり活用に不慣れな人たちに最低限必要な知識を伝えて実践してもらうために伝えてほしい
- 推しコンテンツを布教しよう
感想
「#サイバーセキュリティは全員参加」ですね。ぜひこの機会を利用して、皆さん周りの方に伝えていきましょう！
Session2: AWS re:Invent 2021 Security re:Cap アマゾン ウェブ サービス ジャパン合同会社 シニアセキュリティソリューションアーキテクト 桐山 隼人さん
- re:Inventの振り返り
- 新しくなったInspectorとセキュリティアップデートなどを話していく
- メインはInspector v2
- どういうものか？
- 脆弱性を検知したりネットワーク露出領域をスキャンして検知する脆弱性管理サービス
- もともとはEC2を対象としていたが、ECR(コンテナリポジトリ)にも対応
- 従来のInspectorはClassicと呼ぶように
- 今後はv2の利用が推奨
- メリット
- シンプルで大規模な管理
- AWS Organizationsで集約管理
- SSM Agentと統合(今まではInspectorのエージェントが必要だった)
- 一元的な集約と可視化
- ダッシュボードが見やすくなった
- リスクの高いものを簡単に確認したり
- 自動検出と継続的なスキャン
- ずっとスキャンしてくれてすぐに気付ける
- スコアリングによる優先順位付け
- CVEの重要度に合わせてEC2インスタンス自体がインターネットに晒されているかどうかを加味して実用的なスコアリングを行う
- 対策フロー自動化
- いろんな脆弱性を検出する
- パッケージの脆弱性やネットワーク到達性
- Security HubやEventBridgeなどを経由して自動対応
- S3に出して長期レポート保存
- いろんな脆弱性を検出する
- 料金体系
- こちらを見てね
- 15日間の無料トライアルあり
- シンプルで大規模な管理
- AWSセキュリティ関連のサービスアップデート
- AWS Shield Advanced
- アプリケーションレイヤーDDoS自動緩和機能が追加された
- 内部的にはAWS WAFのルールが自動作成される
- CodeGuru Reviewer機密情報の埋め込み検知
- コードや設定ファイルにパスワードやアクセスキーなどが誤って紛れ込んだ時に検知する
- Lake Formationの行およびセルレベルのアクセス制御
- きめ細かく制御
- 厳しいデータ管理のポリシーがある場合など
- Control Towerデータ所在要件のためのリージョン拒否とガードレール追加
- リージョンの制限などで統制を効かせる
- Amazon VPC Network Access Analyzer
- パケットレスポートスキャンみたいなイメージ
- 設定を論理的に解釈して、ネットワークの到達性を評価して可視化
- S3 Object OwnershipでACLを無効化可能に
- 昔からあるACLを使わない場合に無効化できる
- S3のコンソールにポリシーチェック機能追加
- AWS Shield Advanced
- AWS Cloud Adoption Framework(CAF) V3.0リリース
- セキュリティの観点
- 9つの機能を提供
- re:Post
- フォーラムが新しくなった
- Security Identity & ComplianceのQAもある
- みてみて
- re:Invent 2021リーダーシップセッションサマリ
- 継続的セキュリティ改善が必要
- 摩擦を低くすることが原則
- ユーザーの負荷になるものは抑える
- 複雑な権限設定など
- 戦術
- セキュリティツールは開発者や顧客にとって使いやすいものにする
- ツールを使う人がセキュリティベストプラクティスについて学ぶ
- 無償のトレーニングコンテンツを提供している
- 日本語字幕もある
- インシデント管理
- アラームやインシデント対応計画を作成・自動化
- ランブックを定義して自動化
- エスカレーションなどを自動化
- GuardDuty for Amazon EKSが発表された(今リリースされている)
- MFAを使おう
- こんまり！(動詞)
- 継続的セキュリティ改善が必要
感想
今回のre:Inventもいろいろありますね！リーダーシップセッションにもたくさんいい内容があるので、一つ一つチェックしていってください！
Session3: AWSコンテナセキュリティ最前線 アマゾン ウェブ サービス ジャパン合同会社 Specialist Solutions Architect, Containers 林 政利さん
- コンテナ使っている？
- コンテナのセキュリティやリスクを考えるにはコンテナのライフサイクルに注目する
- Dockerfile
- イメージビルド
- レジストリに格納
- オーケストレータにプル
- コンテナが起動する
- それぞれのステップでどうする必要があるかで考える
- Dockerfile
- ベストプラクティスを守っているか？
- lintとかコンプライアンスチェックとか
- 自動的に動くツールがいっぱいある
- ビルド
- イメージをビルドする環境が安全か？
- ビルド用のSaaSを使うと毎回安全な環境ができるのでオススメ
- 脆弱性対策
- コンテナイメージを作る前に対策しておく
- Shift Left
- アプリケーションをビルドする段階、パイプラインの前の方で脆弱性対策できる
- 有効に働かせるためには条件がある
- コンテナがイミュータブルであること
- スキャンしたイメージと同一のものが実行される
- 定期的にスキャンしてデプロイされること
- セキュリティパッチが適用されたイメージをデプロイ
- コンテナがイミュータブルであること
- 脆弱性スキャンは万能ではない
- 情報ソースにないものは検出できない
- OSや言語が未対応など
- 誤検出もある
- 組み合わせで考えていく
- 情報ソースにないものは検出できない
- ECR Enhanced Scanning
- ECRにはもともとイメージスキャン機能があった
- OSパッケージのみ
- Inspectorとの統合でEnhanced Scanningできるように
- プログラミング言語の脆弱性もチェックできる
- イメージが追加されたら継続的にスキャン
- サプライチェーンの保護
- イメージレジストリ保護
- ECRのアクセス許可を適切に
- コンテナレジストリのホワイトリスト化
- 知っているレジストリのみを使っているか確認する
- AWS Configを使って自動化
- イメージレジストリ保護
- イメージの署名
- ビルドしたイメージの同一性を検証
- 署名の利用はそんなに進んでいないのが現実
- AWSの調査でも10%ほど
- オーケストレータが未対応
- Notary v2が立ち上がっている
- イメージレジストリにAPI追加
- もっと民主化されることが望まれる
- オーケスオトレータの保護
- 管理アクセスの保護
- ネットワークの制限
- ユーザーの管理
- 権限の管理
- コンテナを起動する際
- rootでコンテナを起動しない
- ホストのストレージをマントされたりする
- 特権コンテナを起動しない
- サンドボックスが無効になる
- やりたい放題になる
- rootでコンテナを起動しない
- GuardDutyのEKS対応
- EKSの監査ログを利用して脅威を検出
- 機能を有効化するだけで利用可能
- 特権コンテナの起動や不正なIPからのアクセスを検知
- 管理アクセスの保護
- ホストのセキュリティ
- コンテナはカーネルを共有
- 仮想マシンよりは分離レベルは低い
- seccompによる分離レベルの強化
- 一番簡単なのはFargateを利用すること
- カーネルを共有しない
- 実行時のセキュリティ
- データの保護
- 転送する時、保存する時の暗号化
- ネットワークセキュリティ
- コンテナ間の通信をポリシーで制御する
- Security GroupやNetwork Policy
- ランタイムセキュリティ
- プロファイルを作りそれに従っているか
- データの保護
- まとめ
- ライフサイクル毎対策を考えていく
感想
ライフサイクルの各レイヤーで一つ一つ対策していくことが大切ですね。GuardDuty対応やInspector v2の活用もしっかりやっていきましょう！
Session4: OSS+AWSでここまでできる、DevSecOps！ アクセンチュア株式会社 田原 聖也さん
- DevSecOpsで活用できるOSSの紹介
- DevSecOpsの初歩として最適なOSS+AWS
- ツールの選定の参考に
- 全部やる必要はない
- 特に気になるところから手を付けるといい
- オススメがあったら教えてほしい
- 共通認識の整理
- 理想的には開発者のアジリティやスピードを低下させたり開発ツール環境を変更すること無くセキュリティを実現する
- DevSecOpsは開発者が主役
- なぜOSS+AWSか
- スモールスタートの観点でライセンスコストがかからない
- コントリビュートも忘れずに
- AWSのセキュリティ系サービスは導入が容易
- 実際に取り組むことで必要な要件を洗い出せる
- いきなり高いライセンスを購入してもフィットするとは限らない
- 商用製品は乗り換えが簡単にできない
- スモールスタートの観点でライセンスコストがかからない
- 本題
- 開発フェーズ(コーディング・ビルド・テスト)に絞って紹介
- 無償利用枠が充実している商用製品も紹介する
- コーディングフェーズ
- セキュアコーディング
- 昔からあるのは規約や人手でレビュー
- 辛くなるのでツールも平行利用するといい
- Snyk Vulnerability Scannerは複数の言語対応
- OSSではないけど無償利用できる
- IDEも幅広い
- 機密情報の漏洩対策
- git-secrets
- コミットされないように防ぐ
- git-secret
- コミットしても暗号化
- AWSではあまり出番はないかも
- truffleHog
- 特定のGitリポジトリで機密情報を探す
- git-hound
- 複数のGitHubリポジトリから特定の機密情報を探す
- git-secrets
- セキュアコーディング
- ビルドフェーズ
- 静的コード解析(SAST)
- プッシュされたコードのスキャン
- Amazon CodeGuru
- セキュリティ観点での解析機能が追加された
- 対応言語はJavaとPython
- Boto3を使う運用スクリプトのようなユースケースに向いている
- Snyk Code
- 言語も広い
- GitHubと連携
- SonarQube
- セキュリティ観点の解析機能は正直物足りない
- ソフトウェア構成解析(SCA)
- OWASP Dependency Check
- 対応言語が少ない
- 検知精度に自信がないと公式が言っている
- Snyk Open Source
- 対応言語がかなり広い
- 自動Fix(PR作る)
- OWASP Dependency Check
- コンテナ解析
- ECRイメージスキャン
- ベーシックスキャンは無料
- Inspectorと統合する拡張スキャンは料金がかかる
- trivy
- Aquaに買収された
- ビルド前のDockerfile等のマニフェストファイルもスキャンできる
- Snyk Container
- GUIが充実
- ECRイメージスキャン
- 静的コード解析(SAST)
- テストフェーズ
- 動的アプリ解析(DAST)
- アプリを動かして攻撃を試行する
- OWASP ZAP
- 誤検知が多い、是正も大変
- DASTは性質上使いこなすのが大変
- IaC解析
- trivy
- Terraform, Kubernetesマニフェストファイルも解析できる
- checkov
- Terraform, Kubernetesマニフェストファイルに加えてCloudFormationやDockerfileも解析できる
- cfn_nag
- CloudFormation専用
- CI/CDに力を入れている印象がある
- tfsec
- Terraform専用
- VS Codeプラグインとしても利用できるのでとりあえず入れてほしい
- Snyk IaC
- trivy
- 動的アプリ解析(DAST)
- まとめ
- まずはOSSを活用してスモールスタートしてみよう
- 最新情報を確認しよう
- Snykいいぞ
感想
もうSnyk1人でいいんじゃないかなｗ
まあ実際はそんなことはないんですが、Snykはぜひ試すべきツールですね。OSSからやってみるのは良いアプローチだと思います。ぜひ気になるところから使っていきましょう！
Session5: MSPによるマルチOrganizations管理の裏側 株式会社NTTデータ 奥村 康晃さん
Managed Service Provider(MSP)によるマルチOrganizations管理の裏側（Security JAWS 第24回 発表資料） from NTT DATA Technology & Innovation
- 会社紹介・組織紹介
- いわゆるSIer
- 非常に多くの業界・お客様
- 2レイヤーのCCoE
- 1層CCoEはMSPでやらないといけないことなど
- 2層CCoEは公共・金融・ヘルスケアなどの業界ごと
- 今回は1層CCoEの話
- 体制
- 4-6名
- アカウント数2,000
- なぜマルチOrganizations?
- 複数のAWSアカウントを管理するための仕組み
- 論理的な境界のため分けている
- 請求データが見れる範囲の限定
- AWS SSOやControl Tower等の利用
- 100近くのOrganizationsが存在する状況に…
- Organizations管理の課題とその解決方法
- 構成管理
- OU/SCPがOrganizations未対応
- Terraformは対応済み
- Terraformも検討したが維持コストを考えてCloudFormationを待つと判断した
- しかしそれまでにも対策が必要
- 1層CCoEのスコープは原則同一構成として管理負荷を軽減
- Organizationsからの自由な離脱や参加の禁止
- Organizations管理アカウントで権限を渡さない
- サポートプランの自由な変更を禁止
- メンバーアカウントでRootユーザーを渡さない
- 請求情報をメンバーアカウントからの参照を禁止
- SCP
- 特定IAMロール以外のサポートケース起票を禁止
- SCP及びCloudFormation StackSetsで実現
- 2層CCoEがもつガードレールとバッティングしないように最低限に限定
- SCP周りの実現方法
- OUを分けて請求の参照禁止とする
- 上位のOUでStackSetsからIAM作成
- StackSetsから作成したIAM変更削除の禁止もSCPで設定
- 上位OUを利用することで、OU間移動でIAMリソース削除を防ぐ
- PitinOUを用意して想定外のメンテナンスにも対応可能
- OU/SCPをネストして利用者要望に対応可能
- 既存AWSアカウントへのSCP適用
- 業務に影響を与える可能性が高い
- 既存AWSアカウント向けのOU/SCP/StackSets構成を作って準備期間を容易した
- 追加の上位OU作成
- 動作確認してもらってからOU間を移動してもらう
- Organizations連携サービスの開放
- 管理アカウントでしか利用できないものと、委任できるものがある
- 管理アカウントでしか利用できないものが厄介
- 管理アカウントにIAMの払い出しが必要
- MSPとして管理アカウントを自由に開放できない
- 管理アカウントはSCPが適用できない
- CloudTrailログなどから手探りで最小権限を確認して利用者に付与
- 継続的に見直しや影響確認が必要
- 構成管理
- まとめ
- 多くの課題がある
- 今後のアップデートが待たれる
感想
ほんとにこれは大変なんです(切実)
頑張っていきたいですねー
Session6: インフラ監視だけじゃない！Datadogを使ったAWSのセキュリティモニタリングのご紹介 Datadog Japan 合同会社 森 祐孝さん
- おまけでLog4Shellの紹介もしたい
- Datadogとは
- クラウド時代のモニタリング&セキュリティ基盤
- IT全体を可視化
- いろんなチームが横断して見れる
- サイロを破壊することを目的に設立した
- APM/Logs/UXなどを追加していって最近はセキュリティモニタリングも
- セキュリティに取り組む理由
- DevOpsチームとセキュリティチーム間のサイロを破壊する
- Datadogのセキュリティ
- オブザーバビリティ
- ログ管理
- インフラ監視
- APM
- セキュリティ
- Cloud SIEM
- Cloud Security Posture Management
- Cloud Workload Security
- Application Security
- ベータ
- RASPやApplication in WAF
- オブザーバビリティ
- デモする
- CSPMから
- CISで各クラウド
- PCI DSS / HIPAA / GDPRなども対応
- AWS CISはv1.3.0
- 検知はSlackにアラートが上がってくる
- どのように対応するかのメッセージが表示
- リンクから詳細を確認
- Log4Shell
- アプリケーションセキュリティの設定を入れておく
- シグナルが出てくる
- どのIPからリクエストされているかとか可視化
- トレース情報をたどってターゲットとどのようなやり取りをしているか確認
- Suggestが出てくる
- 今回はIPをWAFでブロックするなど
- インシデントを作成することが可能
- 攻撃後リバースシェルが起動されていることも確認できる
- Log4Shell専用ダッシュボードがある
- どんな検知があるか
- どんなIPがあるか
- HTTP以外にどんな通信があるか
- プロセス一覧
- などなど
- CSPMから
- まとめ
- はじめるのは30分でできる！
- 14日間の無料トライアルもあるよ！
感想
いろんな集約可視化にも対応していて、様々なRoleの人が利用できるのでいいですね。
Application Securityの拡充と使ってみたレポートに期待ですね。
Session7: 9/2のDX障害を迂回できるマルチリージョンTGW+DXGWに移行した話 株式会社野村総合研究所 矢野 純平さん
- 2021/09/02に発生した東京リージョンのDX障害
- 東京リージョンや大阪リージョンでDXを冗長化していても迂回できないのでは
- AWSさんからワークアラウンドを提示してもらった
- TGW+DXGW構成
- Inter-Region Peeringにより大阪リージョンを経由して東京リージョンの通信を通す
- できるだけ早くやろう
- レイテンシーよりサービス停止のほうが問題なのでやると判断
- 12/5にリリース済み
- リリース前の構成
- DXロケーションはCC1/TY8、OS1を利用
- Private VIF + VGW
- 大阪リージョン利用なし
- リリース後の構成
- マルチリージョンTransitGW + DXGW構成に行こう
- TranssitVIFへ変更
- 大阪リージョンはTransitGWを利用する最小構成
- 大阪リージョン本格活用のDRも別途進めている
- リリース前その2
- インターネット接続はTGWを経由してインターネット基盤VPC経由
- VPC感はPeering構成
- リリース後その2
- インターネット接続後VPC間接続は移行せず
- オンプレ向けDX接続のみ変更
- テスト環境にDXがない
- テスト環境はVPNを使っていた
- テストVPCを作った
- TransitVIFを追加
- PrivateVIFからの移行手順も確認
- 移行STEP
- 非業務系を実施して、2週間後業務VPC
- 移行前の構成
- PrivateVIF経由
- 事前準備
- DXGW作成
- TransitVIF作成アタッチ、BGPピア接続
- 何かしらのルート配布が必要
- ルーティングの切り替えは通信方向毎
- オンプレ -> AWS経路の切り替え
- TransitGWとDXGWの関連付け設定においてルート配布にCIDRを追加(上限20CIDRなので注意)
- Local Preference、AS Path Prependの設定によって制御可能
- ステートフルな機器に注意
- AWS -> オンプレ経路の切り替え
- VPCルートテーブルに置いてオンプレ向け経路をTGWを宛先として追加して経路が変わる
- StaticがBGPより優先される
- TGW + VPCの組み合わせでVPC側はStaticのみ
- 移行後
- オンプレ側の経路変更はPrivateVIFのshutdownで実施
- 東京リージョンのVPCのCIDRは東京TGWから、大阪リージョンのVPCのCIDRは大阪TGWから
- 迂回させてみた
- 必要なオペレーション
- 東京TGWからの経路配信停止
- 大阪TGWからの経路配信追加
- 東京TGWでオンプレ向けStatic(大阪TGWへ)追加
- レイテンシは4msから20ms程度に上昇
- 必要なオペレーション
- 設計のポイント
- TGW + VPCの組み合わせではルーティングがStaticのみ
- TGW + DXGWで1つのTGWから配信できるCIDRが20
- TGW + DXGWの関連付けは最低1つのCIDR配信設定が必要
- 東京、大阪(異なるTGW)から同一CIDR、重複CIDRは配信できない
- TGW、DXGW、CGWで異なるAS番号を利用する必要がある
- TransitVIFとDXGWは同一アカウントが所有する必要がある
- DXGW関連のAWSCLIv1だと使えない、v2が必要
- TransitGWが障害になるとどうか
- TGWと東京リージョン全体の障害にならなければマルチリージョンTGW + DXGW構成なら大丈夫
- VGW + DXに戻す手順も用意
- まとめ
- マルチリージョンTGW + DXGW構成は専用線接続のメリットを残したままDX障害に対応できる
- TGW障害に対するシングルポイントが残る
- 現状は手動切替が必要
- ネットワークの本にコラムがあるよ
感想
がっちょり知見がまとまっていて参考になりますね！多分あとからじっくり確認する必要がありますねｗ
さいごに
すごく内容が濃かったです…
#サイバーセキュリティは全員参加 しようね！
25
