この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第25回が開催されましたのでレポート致します。
Security-JAWS【第25回】 勉強会 2022年5月30日(月) - Security-JAWS | Doorkeeper
動画
レポート
Session1: 「AWSセキュリティのベストプラクティスに関する利用実態調査」のお願い Security-JAWS 吉田 浩和さん
Security-JAWSからのAWSセキュリティに関するアンケート！！です
AWSを利用している方、特にAWSのセキュリティに携わっている方にご回答頂きたいです！
- みなさん、AWSのセキュリティベストプラクティスってどこまでやってますか？
- 周りの人がどこまでやっているか気になりませんか？
- 運営メンバーもよく聞かれます
- 過去のアンケートからも
- 根強く「どこまでやってますか？」とか聞かれる
- 状況を確認してみる
- AWSからはたくさんセキュリティベストプラクティスのドキュメントなどの情報が発信されている
- 利用者がどう活用しているかはあまり知られていないのでは
- 仮説
- ベストプラクティスから具体的にどうしているか、がつまづきポイントでは
- セキュリティの選択肢が多いのでは
- 考えても仕方ないのでアンケート作りました！
- 答えていただいたら後ほど生データも共有します
- アンケートに答えるだけでもセキュリティベストプラクティスの学習につながる
- 難しいんじゃないの？
- 必須回答と任意回答を分けているので、気軽に回答してね！
- ぜひご協力お願いします
[拡散＆回答のお願い！]
「AWSセキュリティのベストプラクティスに関する利用実態調査」について、Security-JAWSからのお願いになります。https://t.co/WP3zyZc08Xこちらの回答に少し長い内容とはなりますが、是非とも回答のご協力をお願いいたします。#secjaws #secjaws25 #jawsug
— Security-JAWS✴︎0825secjaws26 (@security_jaws) May 30, 2022
Session2: 世界のクラウドコンプライアンスから アマゾン ウェブ サービス ジャパン合同会社 セキュリティアシュアランス本部 本部長 松本 照吾さん
- セキュリティアシュアランス本部は規制当局と話をする仕事
- 世界でも同じようなお悩みを受けている(各国規制当局から)
- 先日行われた白浜シンポジウムの情報危機管理コンテストを支援していた
- 全人類に読んでもらいたい
- 技術的なお問い合わせに関するガイドライン | AWS サポート
- よくあるコンプライアンスの話題でAWSってどういうスタンスなの？
- ネタ元
- データ主権
- Data Sovereignty
- データが収集もしくは関連する国の法律と統治機構に従うという概念
- そもそもの現実
- 今まで国とかシステムのことを考えると、ITは国の中に収まっていた
- クラウドやインターネットでは国境がなくなる
- データの国を超えた活用が当たり前になる
- 本当にそれがいいのか、という考え方が出てきた
- 取り扱うデータは国の主権を尊重して扱われているのか？
- EUを発端とした調査
- データを扱うことがビジネスの妨げになっているのでは
- クラウドプロバイダーがどこの国か気になるか？
- 16%の企業が気にしている
- データ主権とクラウドの課題
- 域外に保管されている顧客データを合法的にアクセスして要求できる権利
- 国家の安全保障に関して定められた外国の町長や監視プログラムの影響
- 国内補完やデータ転送時のデータに対する個人のプライバシー保護
- 懸念点も多い
- コスト増加の懸念
- 主に米国に対する重宝・監視法への懸念
- データローカライゼーション
- クラウド主権を考える要素
- 補完をどこでやるのかコントロール
- データをローカライズすることはセキュリティの向上ではない
- データの場所はサイバー脅威のリスクを軽減しない
- 適切なアクセス制御とセキュリティ保護が求められる
- 事業継続性、可用性に対する制限の増加
- バックアップやリカバリにおけるクロスリージョン活用への阻害
- ローカルプロバイダの活用
- 多くの企業は大規模なクラウドプロバイダと同等のセキュリティメリットを提供するためのリソースや専門知識を持ち合わせていない(IDC)
- GAIA-X
- 政府主導でデータ流通基盤の必要性
- EUが実施
- 加入時に原則への準拠を表明
- EC外でもECの考え方を尊重してね
- AWSもGAIA-Xに加入している
- 高いセキュリティ及びデータ保護を確保
- EUのデータ主権を尊重している
- もともとお客様でコントロールできる
- 世界をリードする技術へのアクセス可能にする
- クラウド法
- CLOUD法への誤解
- 米国のプロバイダを利用していると米国の期間が知らないうちにデータにアクセスしてしまう
- 政府が許可のない開示
- 日本の事業者には適用されない
- CLOUD法は何のため
- 捜査当局が犯罪に関する情報やデータに強制的にアクセスするための司法手続きを明確化した法律
- 証拠の強制的な提供には裁判所が発行する霊場が必要
- 無制限のアクセスをさせないことが定められている
- 多くの組織が対象となる
- 1980年代に施工されたSCAの延長線にある法律
- 日本でも対象
- 法執行機関が直接データを抽出することを認めていない
- プロバイダーが開示
- 要請をまのがれる可能性がある
- AWSの実態
- 請求に対してほとんど開示していない
- CLOUD法への誤解
- 重要になっていくもの
- データのオーナーシップは利用者に
- 暗号化・鍵管理の重要性の高まり
- 自分でコントロールしよう
- まとめ
- 主権のための主権の誘惑をさけて、価値を決めよう
感想
まさに色んな国でデータ利用の規制などが出てきて現場は大変になっていると思います。新しい考え方の流れは要チェックしていきたいですね。
Session3: デベロッパーファーストなセキュリティプラットフォーム Snyk 紹介 (Lambda、CodePipeline、ECR とも連携可！) Snyk 相澤 俊幸さん
- Snykとは
- so now you know(Snyk)
- あえて訳すと「これでわかったでしょ？」
- ひと目で脆弱性を見つけられる
- Snykをご存知でしたか？
- moしかしたら知らずに使っているかも
- 実は
docker scanで使われている - Amazon InspectorのECR拡張スキャンでSnykの脆弱性データベースが使われている
- 無料でサインアップ出来るので使ってね！
- Snykを使って迅速な開発とセキュリティの両立ができる
- Developer Securityという考え方を持っている
- これからの時代に必要
- DevOpsやアジャイルなど開発手法が変わっている
- セキュリティ対策は変わっている？
- セキュリティ対策も継続的に行わなければ
- 多くの現場ではリリース直前でスキャンして対策を始めている
- イノベーションの足かせとなる従来型セキュリティ対策
- あるいはセキュリティ対策をおろそかにしている
- Developer Securityが必要
- 開発者がセキュリティ対策の主役になり、開発の全行程でセキュリティを適用する
- Snykは全行程で利用できる
- コーディング、ソースコード管理、CI/CD、本番環境それぞれで使える
- 様々なツールと連携できる
- アプリで拡張できる
- Log4Shell対策でもSnykが活躍
- 脆弱性の検出が自動的に行われる
- Slackなどにアラート、修正方法も開発者に伝わる
- 12/10(金)に周知された
- 休みの間に殆どのユーザーが対応完了した
- so now you know(Snyk)
- 4つの製品群
- Open Source
- Container
- IaC
- Code
- 1つの製品ですべて対応できる
- デモ
- Snyk Open Sourceについて
- いろんなOSSを使っている
- たくさんの脆弱性が混入してしまう
- Log4Shellなどの大きな脆弱性が今日見つかるかも
- 今回は2つのデモ
- デプロイ済みのアプリケーションから検出する
- Git連携で検知する
- Projectという画面
- スキャン結果
- Lambdaとの連携
- 5分くらいでできる
- IAM Role作って設定
- severlessのアプリをスキャン
- 数秒でスキャン終わり
- どんなパッケージが含まれているかがチェックされる
- 10個ぐらいのライブラリを検知
- ライブラリツリー表示される
- マニフェストに書いてないものもわかりやすく見れる
- 10個の脆弱性が見つかっている
- OSSの場合もっとたくさん見つかることも
- Snyk固有のスコアが付いている
- Priorityスコア
- PoCがあるか、攻撃しやすいかなどを基にスコアリング
- スコア順に並んでいるので上からやっていけばいい
- どこから混入しているか、どう修正すればいいかかかれている
- 開発者が自身でスキャンして自身で修正できるようにしている
- Snykの脆弱性データベースで詳細を確認することもできる
- Git連携スキャン
- 同じくProject追加
- GitHub連携
- 先ほどと同じアプリをチェック
- 同じく10個検知
- 先程より上流で検知している
- メリットが有る
- 修正ボタンを押すとPRが作られる
- 全部まとめて修正される！
- 全部Snykに任せられる
- Snyk Open Sourceについて
- 特徴の1つ
- 自動修復
- Snykの脆弱性DB
- 見つけるために非常に重要
- 注力している
- 様々なセキュリティベンダーの裏側で採用されている
- まとめ
- Developer Securityを実現
- 開発者用のセキュリティツール
- 開発ツールと連携
- 使いやすい
- 自動修正
- データベースに注力している
感想
自動修正はやばい。PR作ってくれるのすこ。Snykしか勝たん。
Session4: AWS Lambdaにおけるセキュリティリスクと対策 株式会社Flatt Security / 情報科学専門学校 森岡 優太さん
- Flatt Securityは開発者のための次世代セキュリティサービスを届ける
- セキュリティ診断やプロダクトの提供
- 以前書いたブログをベースにした内容を紹介
- サーバーレスのセキュリティリスク
- CNCFによる定義
- FaaS
- 関数単位でデプロイや実行ができる
- BaaSは今回対象外
- サーバーレスの主なセキュリティリスク
- 利用するサービスの設定不備
- アプリケーション実装不備
- OWASP Serverless Top 10がある
- CSAのサーバーレスアプリの最も重要な12のリスク
- 今回はアプリケーションの脆弱性についての話
- サービスについては別ブログがあるよ
- Cognitoについて
- AWS Lambdaで考えられる脆弱性攻撃
- AWS Lambda
- 7種類の言語に対応
- 利用場面
- API Gatewayと連携してAPIで活用
- S3イベント
- DynamoDBイベント
- 想定活用例
- WebアプリからS3へアップして書こう
- WebリクエストをLambdaで解析、レスポンス生成
- いろんな脆弱性が考えられる
- 責任共有モデルの上の方、ユーザーの責任
- サーバーレスのアプリでも脆弱なソースコードやライブラリを利用することでリスクになる
- AWS Lambda
- AWS Lambdaのセキュリティリスク
- Lambda環境変数からクレデンシャル取得
- IAM Roleのクレデンシャルが環境変数に格納されている
- S3やDynamoDBに接続する場合に、その権限を付与している
- 攻撃者が取得できるとS3が見れたりする
- OSコマンドインジェクション、XXEなどで取れる
- 3つの環境変数が取得できれば攻撃できる
- さらなるリスク
- 漏洩した権限から不正操作、特権昇格、コインマイニングなど
- Lambdaを対象としたと思われるマルウェアも出てきている
- ソースのハードコードクレデンシャル取得
- API KeyやDBの認証情報、S3バケット名などがハードコードされる
- Runtime APIで内部から機微な情報取得
- Lambdaの内部APIの1つ
- リクエストとレスポンスを直接
- レスポンスに機微な情報が含まれている可能性がある
- 例えばSSRFでRuntime APIを実行してレスポンスを取得できる
- Lambda環境変数からクレデンシャル取得
- AWS Lambdaのセキュリティ対策
- アプリケーション
- 安全に実装する
- Secrets Managerを活用する
- ハードコーディング対策
- git-secrets
- gitleaks
- GitHub自体の機能でもスキャンできる
- ライブラリもセキュアに
- CI/CDで最新バージョン適用できるといい
- Lambda Layersでライブラリを共通管理するといい
- IAM Role
- 最小権限を意識
- 最小権限実現への4ステップアプローチ
- Lambdaのコード署名
- デプロイ時にコード署名を検証できる
- メリット
- 改ざんされたコードや信頼性のない先からデプロイを検証できる
- その他
- モニタリングや監査
- CloudWatch
- CloudTrail
- X-Ray
- Config
- Lambda Function URLs
- 最近出た
- API GatewayなしでLambdaにURLを付与して直接実行できる
- 設定不備でリスクになる
- 意図しない公開やバックドア利用など
- モニタリングや監査
- アプリケーション
- まとめ
- サーバーレスなLambdaでもセキュリティリスクは存在する
- 適切な対策・運用を行う
感想
AWS Lambdaでも適切なセキュリティ対策が必要ですね。何故かサーバーレス安全神話を聞くこともありますが、ちゃんと怖がってちゃんと対策しましょう。
Session5: CloudSIEM Enterprise＋CloudSOARでSOCを自動化 Sumo Logic Japan株式会社 Senior Security Solutions Engineer 神崎 哲朗さん
- Sumo Logicとは
- 2010年に設立されたクラウドSIEMのパイオニア
- Cloud NatigveにSIEM/SOAR/ObservabilityをSaaSで提供
- AWSやアプリやマイクロサービスなど様々なものからログを収集
- SIEMとしても使えるし、運用でもビジネスでも使える
- SIEM/SOARとは
- SIEM
- 様々なデータを一元管理し、分析/可視化/検知/保管
- 単一サービスではなく統合的に監視
- SOAR
- インシデント検知後の対応を自動化
- 特定・防御・検知は別の製品で
- アラートが出た後の動作を自動化
- 情報収集・調査
- 証跡保存
- レスポンス
- 検知から事後対応まで効率化しましょう
- Sumo Logicのここが好きだ！セキュリティ編
- マルチテナント型クラウドSaaS
- サーバー・ディスクケアが不要
- AWS東京リージョン上に構築されている
- SIEM
- デモ
- ブラウザからアクセスする、あるいはAPIでアクセス
- オンプレやVMはない、完全にクラウドSaaS
- 予めログは入れている
- 導入する場合にはログの取り込みやすさを気にするといい
- Sumo LogicはIAM Role作成用CloudFormationのテンプレート自動生成
- CloudTrailのログを確認
- IPで絞ったり
- 集計したり
- グラフ化したり
- 自分でクエリも出来るが、予め作ってある可視化テンプレートがある
- すぐに可視化できた
- GEO IPでマッピングできる
- 誰がどこからどんな操作をしたかすぐにわかる
- GuardDutyのテンプレートもある
- 緊急度の高いものをすぐに見れるようにしたり
- アカウントやSeverityをベースに集計したり
- Cloud SIEM Enterprise
- また別の画面
- 相関分析を自動化してアラートの絞り込みをする
- かっこいい画面
- アラートが53万件ある状態
- 人が見るのは大変
- 自動的に7件に絞り込まれている
- 相関分析のルールを内蔵している
- AWSだけで67種類ある
- エンティティを基にした分析がされる
- ホストやIPアドレスを基に分析
- スライドで解説
- ログのカテゴリではなく、IPやホストなどエンティティをベースに横串で分析
- 今回はdevserverという名前のホストが対象
- ホストベースでアラートを集約
- GuardDutyのアラートが上がっている
- マイニングされているっぽい
- 他にもThreat Intelで怪しいIPと通信している
- CPU使用率もすごく上がっている
- カーボンブラックでもコインマイニング検知
- それぞれの検知でスコアが積み重なって、一定上のスコアでSumoがアラートを出す
- ルールがMITRE ATT&CKに紐付いている
- SOARで対処
- 別の画面
- 予めPlaybook(台本)を仕込んでおく
- 検知したらJiraチケット作成
- インスタンスの調査
- インスタンスの停止してバックアップ
- まとめ
- 相関分析と自動対応でいい感じに対応できる
- 無料トライアルできるよ
感想
ログが大量にあるクラウド時代には相関分析や自動化が大事ですね。画面かっこいい！
Session6: 閉域要件におけるEC2のアクセス制御 ～SaaS・Private Linkの罠とNetwork Firewallの活用～ みずほリサーチ&テクノロジーズ株式会社 松尾 優成さん
- みずほのAWS利用状況
- 重要情報を扱うシステムの場合閉域網利用が主流
- AWSと自社設備とハイブリッド
- 前回閉域網でのS3関連ポリシーを紹介した
- 今回話すこと
- Network Firewallの活用
- Session Manager利用
- Network Firewallの話
- AWS Network Firewallとは
- URLフィルタリングなどのマネージドサービス
- 専用のFirewall Endpointを設置
- 構成例
- TGWを中心にVPCなど接続
- 出ていくVPCにNetwork Firewall経由で出る
- EC2でチェックして出ていく
- ステートフルドメインのリストフィルタで制限
- Network Firewallにたどり着いた流れ
- 当初の想定
- Private Link経由を検討
- バージニアリージョンでSaaS Private Link
- 本当は国内リージョンを使いたかったが制約のため断念
- TGWクロスリージョンもできなかった
- 半年後
- Private Link経由でウイルス対策ソフトを利用できなくなった
- SaaSで仕様変更
- マネージャーサーバーのエンドポイントURLが変更
- 新しいURLではPrivate Link未対応
- 代替案を検討
- Network Firewallが東京リージョン対応
- ついでに集約できそう
- 当時Blackbelt前にDevelopersIOやaws-samplesを参考にした
- 結構な構成変更だったけど対応できた
- 嬉しかったこと
- 基本構成が東京リージョンのみで完結した
- アウトバウンドが集約されハブ＆スポーク型になった
- 運用課題だった閉域要件のOSパッチ適用が楽になった
- 悩んだこと
- AWS宛のVPCエンドポイントも一部廃止してNetwork Firewall経由にすればよかった？
- 各VPCにVPCエンドポイントを作るか
- S3など通信量が多くなるならVPCエンドポイント経由がお得
- 通信量が少なければNetwork Firewallにする？
- VPCエンドポイントポリシーでアクセス先制御
- Network Firewall経由の場合にはクレデンシャル持ち込みの場合に流出の経路がある
- VPCエンドポイント利用を継続した
- AWS Network Firewallとは
- Session Managerの話
- 社内で新規導入予定のCloudHubで予期せぬ自体が発生した
- 開発者からDXとTGW接続のためTransit VIFの提供を依頼
- NW担当者から個別案件に払い出せないとレスポンス
- なんとかなりませんか？
- 社内共通基盤にVIFを払い出すのでなんとかならない
- TGWとDXが接続できない
- どうするか
- 1. VPCを挟む
- 直接伝搬できない
- 2. DXGWを各VPCにつなぐ？
- ルート変更が必要
- 1. VPCを挟む
- 試行錯誤した結果Session Managerを採用
- DCからDX経由でVPC接続、VPCe経由でSession Manager利用
- DC側の運用者がIAM Roleを引き受ける
- クレデンシャルを使ってポートフォワーディングを実行
- 利用対象側VPCにVPCエンドポイントを作る
- Session Manager利用のために3つのエンドポイントが必要
- 送信側VPCにもいる
- Network ACLではport443を許可する必要がある
- Session Managerの閉域利用は本当にだいじょうぶ？
- リスク
- 社外クレデンシャルを持ち込まれたときにデータ流出のリスク
- 外部からSession Managerが利用される
- どう対策するか
- ポイント4つ
- アクセスキーIAMポリシー
- IAMではAssumeRoleを許可
- アカウントとRole名を指定する
- キー漏洩時のリスクも考え最小権限
- VPCエンドポイントポリシー
- aws:PrincipalAccountでアカウントを絞る
- 別アカウントへの通信を止める
- IAM Role信頼ポリシー
- 漏洩したクレデンシャルを使えないようにSourceVPCeを入れる
- ついでにMFAを強制する
- Trailで追跡するためにセッション名をIAMと一致させる
- IAM RoleのIAMポリシー(スイッチ後)
- SourceVPCeが重要
- StartSessionを絞る
- アクセスキーIAMポリシー
- 社内で新規導入予定のCloudHubで予期せぬ自体が発生した
- これはデータ境界かもしれない
- 詳しくはこのへん
感想
閉域網利用時のアクセス制御のいい知見ですね。厳密なアクセス制御は大事ですのでぜひこれを活用していきたいですね。
Session7: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー
セキュリティ対策は様々な領域で対応が必要になると思っています。様々なある中でどのような考え方で対応の優先度をつけられているのか、皆様の考え方を知りたいです。
- 何のデータが乗っているの？それが漏洩したら誰が謝るの？って聞く
- 本当はどういう優先度でやらないといけないのか当事者が知っているはず
- リスクは掛け算
- 対応のしやすさも大事
- 直ぐにできる対策はすぐにやろう
- つまりGuardDutyとSecurity Hubはすぐに有効化しようね
Control Tower(Organizations)配下の予防適当性として、どのくらいSCPを活用していますか？SCPは強力な一方、不具合時の影響範囲が大きいので、デプロイやテスト周りをどのように行っているか、事例があれば知りたいです。
- 極端にはOrganizationsを分ける
- 順番に適用していく
- Control Towerで提供しているものを全部使う必要はない
- あんまり修正する回数も多くないので頑張る
- CloudShellとかLambda URLsとかはとりあえず止めて、リスクを明確に洗い出せたら開放していく
CISベンチマーク活用事例(運用成功するための秘訣、ポイントなど)
- セキュリティ厳しくしてビジネスがドライブしないと違う
- どうやってログ分析するかの運用設計とか
- 検出したものを直すのはコードに組み込みなさい
- 同じアラートを2回手動で対応しない
- 本当にCISベンチマークがいいのか？
- AWSだけならSecurity HubでAWS基礎セキュリティベストプラクティスを使おう
- 以下参考
ランサムウェア対策をテーマにして開催をお願いします。
- 今は暴露もポイントになる
- 暴露まで考えると自分たちで実施する暗号化についても意識する必要がある
- 侵入経路はエッジ、クライアントPCであることが多いので、ソチラの対策も重要
- AWSはそこから受ける被害を抑える側
- 最近だとAmazon FSx for NetApp ONTAPだとランサムウェアの検知や封じ込めなどがいい感じに出来るらしい
さいごに
今回も幅広い話でした。
個人的にはSnyk最高だなと思いました。セキュリティ対策をシフトレフトして最初からしっかり対策して、運用していきたいですね。
25
