この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第18回が開催されましたのでレポート致します。
Security-JAWS 【第18回】 勉強会 2020年8月28日(金) - Security-JAWS | Doorkeeper
レポート
Session(-1): JAWS SONIC 2020 / MIDNIGHT JAWS 2020 実行委員長「JAWS SONIC 実行委員からのお願い」
- ぶっ続けのイベントやります！
- https://jawssonic2020.jaws-ug.jp/
- JAWS-UGはAWS User Group - Japanの略
- 今は70ぐらいの支部がある
- Rave-Upというテーマ
- 長時間騒ぐぞ！
- 2020/09/12(土) 17時 開始 〜 2020/09/13(日) 17時 終了
- 1日以上やってます
- お昼のイベント
- Jeff Barrに登壇してもらう！
- 50の支部が参加して色んな話をしていく
- Finの話とかコンテナの話とかいろいろ
- 今後もいっぱいセッション追加されます
- ミッドナイトのイベント
- 早い者順！
- 誰が速く環境を構築できるのかという運動会もやる！
- 楽しんで、アウトプットしよう
- アウトプットしないのは知的な便秘
- イベントをぜひ色んな人に拡散してください！
Session0: アマゾン ウェブ サービス ジャパン株式会社 沼口 繁さん「本日のライブ配信環境ざっくりと」
- noteでも紹介している
- Amazon WorkSpacesを利用している
- 5つのディスプレイに囲まれて配信している
- 今回は登壇者はZoomに集まっていて、WorkSpacesからその画面を配信している
- 最初からこのような環境ではなかった
- 試行錯誤して現状の環境になった
- 興味がある方はnote見てみてください！
Session1: アマゾン ウェブ サービス ジャパン株式会社 金杉 有見子さん「本番デプロイ前にできること ~ Amazon CodeGuru のご紹介~」
- ECRのスキャンの話もさせて頂く予定だったが今回は都合が合わずCodeGuruの話だけ
- コードレビュープロセスにおける課題
- コードレビューの目的
- プロダクトの欠陥をなくす
- 品質を維持する
- コードレビューは正しく動くかという点に重点を置きがち
- 人材の確保が課題になる
- コードが増えるとレビュアーの負担になる
- コードレビューの目的
- Amazon CodeGuruとは
- コードに血管がある部分やアプリケーションで最も実行コストが高い箇所を特定し、改善方法を含め推奨事項を生成する機械学習をベースとしたサービス
- CodeGuru Reviewer
- バグなどを特定
- 品質の維持につながる
- Java対応
- CodeGuru Profiler
- パフォーマンス状況を可視化
- 実行コストが高いコード行を特定
- JVMに対応
- 2つは別の機能
- AWS AI/MLスタック
- Amazon Codeサービスの系列ではなくてAI/MLに含まれている
- AIサービス郡はAIに知見がなくてもかんたんに利用ができるサービス
- 東京リージョンでも提供されている
- 位置づけ
- Reviewerはレビュー時にレビュアーが利用する
- 動作方法
- RPベースのレビュー
- Full Repository Analysis
- 動作イメージ
- 管理者がコードリポジトリの関連付けを行う
- 開発者が変更してPR
- Reviewerが推奨事項をコメント
- 開発者はコメントへのフィードバックができる
- 機械学習のサービスなのでこのフィードバックを元にどんどん賢くなる
- Analysisは導入段階と定期的に利用するユースケースがある
- 対応リポジトリ
- CodeCommit
- GitHub
- Bitbucket Cloud
- レコメンデーション
- いろいろある
- AWSベストプラクティスも含まれている
- AWS APIが正しい使い方ができているかなどをチェック
- はじめ方
- リポジトリを選択して関連付け
- シンプル
- レコメンデーションのサンプル
- PRベースの場合、PR作成後15分以内に確認できる
- 例はリソースリークの可能性があるよ、というコメント
- リファレンスもつけてくれる
- Emojiでリアクションする
- レビューの結果はAPIでも取れる
- セキュリティ
- CodeGuruでは集めたサーバーサイド暗号化されている
- 転送はTLS
- 他での利用は行わない
- 料金
- RPベースとAnalysisでそれぞれ
- 90日間の無償期間がある
感想
仕組みでレビューを助けてもらえるのは非常に嬉しいですね。AWSベストプラクティスや機密データの漏洩に対応しているのは非常に嬉しいですね。コードの脆弱性チェックはまだのようなので対応に期待したいですね！
Session2: トレンドマイクロ株式会社 シニアソリューションアーキテクト 姜 貴日さん「コンテナ・サーバレス環境のセキュリティでトレンドマイクロがお手伝いできること」
- 今日のスコープ
- AWS Lambdaの責任共有モデル
- IaaSよりもだいぶお客様領域が少ない
- 今回はWebアプリケーション自身の保護と、Webアプリケーション経由でのデータ保護をお手伝い
- AWS Lambdaの責任共有モデル
- Trend Micro Cloud One
- 名前に聞き馴染みがないかもしれないが、トレンドマイクロが出しているクラウドで利用できる製品群
- この内Workload Securityが今までDSaaSと読んでいたところ
- 他にもNetwork SecurityやContainer Securityなどがある
- 今回はこの中のApplication Security
- Cloud One - Application Security
- RASP(ランタイム保護)方式を採用、アプリケーション自身でセキュリティ対策する
- 言語はJava / Node / Python / PHP
- 機能
- 悪意のあるペイロード
- SQLインジェクション
- リモートコマンド実行
- オープンリダイレクト
- 不正なファイルのアップロード
- など
- アーキテクチャ
- アプリケーションが動くときにHookして動く
- 管理者はSaaSの管理画面から結果を確認したりポリシーを設定したりする
- ユースケース
- ECサイトでFargateがあるような場合
- CF - ALB経由でアプリケーションに攻撃される
- 情報漏えい
- 改ざん
- 不正な操作
- 運営の妨害
- など
- Application SecurityはFargate上で動かす
- AWS WAFでもいいのでは？
- 動作するレイヤーの違い
- WAFとApplication Securityは動く場所が違う
- WAFは通常インターネットよりで検査して検知・防御
- Application Securityはアプリ上で動いて実際の動作を見る
- 検知方法の違い
- WAFはシグネチャベース
- Application Securityではシグネチャとアプリの動作も制御
- ポリシーに基づいて動きを制御できる
- 提供機能の違い
- 以下のようなものができる
- 意図しないリダイレクト
- 不正なファイルアクセス
- 不正なファイルのアップロード
- どういったところを保護したいかで検討するといい
- 以下のようなものができる
- デモ
- Webアプリの不備から機密情報を搾取
- API Gateway -> Lambdaの環境
- S3の機密情報を搾取する
- うっかりLambdaの権限を広くつけてしまっている状況
- Application SecurityをLambda上で動かして止める
- デモサイト
- 見れないものが見えてしまう状態になっている
- /etc/passwdなどにアクセスできてしまう
- クレデンシャルを取得できてしまった
- 攻撃者が入手したクレデンシャルでS3へアクセスしてみる
- まだ見れない
- アカウント情報などを確認
- IAM Roleの名前を確認
- Roleの名前を指定してポリシーをアタッチ
- 再びS3にアクセスして機密情報を搾取できた
- ここから防ぐデモ
- すでにLambdaにApplication Securityが導入はしている状態
- Lambda Layerで導入している
- ただ検知モードで止めていなかった
- 検知した結果を確認
- Not Blockとなっていた
- 設定変更してブロックする
- Application Securityがブロックしてくれた
- 管理画面からブロックも確認できた
- ユースケース
- デモはLambdaだったがFargateでも、アプリケーションに入れて防御できるので利用可能
- 一度攻撃が成功すると様々な部分に派生する
- Application Securityではアプリケーションの実行箇所で止められる
- 他の製品ではFile Storage SecurityでS3の保護、Container SecurityでECRの保護ができる
- まとめ
- IaaSだけでなく、FaaSでも責任共有モデルを意識する
- WAFとApplication Securityは動作するレイヤーが違いできることも違う
- Webアプリケーションへのリスクはクラウドでも基本は同じだがクラウド特有のリスクもある
感想
EC2だけでなくコンテナやLambdaでもアプリ実行側で防御できるのはいいですね！他のS3保護も気になります。
下記も参考になります
Session3: サイバーマトリックス株式会社 四柳 勝利さん「CloudFrontを活用してアタックサーフェスを減らした対策を導入してみる。」
- 夏休みの研究みたいなタイトルでいく
- セキュリティをかんたんにしていこうというコンセプトにやっている会社
- 今回は製品の話より一般的な話
- Attack Surface
- 攻撃可能領域とか攻撃で狙われるポイントのこと
- これをいかにに守るかが大事だが、減らすことも大事
- 例えば最小権限やFirewallのポリシーを絞るなど
- S3編
- CloudFront - S3の構成で提供するサイト
- S3に直接アクセスできるようにせず、CloudFrontからのみアクセスできるようにする必要がある
- Origin access identityを作成し、これをS3で参照するように設定する
- こちらも参考になります
- 非常にかんたんに設定できる
- ホスト編
- CloudFrontからEC2とかALBへアクセスする
- EC2やALBの直接アクセスできるFQDNがある
- このFQDNはある程度推測できるのでスキャナーとかが来ることがある
- これも直接アクセスさせないことでAttack Serfaceを減らすことができる
- Security Groupでアクセスを絞る方法がある
- AWSからCloudFrontのIPアドレスのリストが公開されているのでそれを利用する
- アウトバウンドの話
- アウトバウンドを絞らないことも多い
- 万が一やられたらC&Cサーバーと通信することもある
- 最小限に設定しておくといい
- 外部DNSの制限をしておくといい
- 実際にAttack Surfaceが多いサーバとCloudFrontだけのサーバをWAFで検知したものを比較
- 制限しているものが大きく攻撃の回数が減っている
- 対策の有効性がわかる
感想
めちゃくちゃ丁寧でわかりやすい話でした。Attack Serfaceを絞るのはとても大切ですね。
CloudFrontからのアクセスに絞る方法は下記も参考になりますのでぜひ見てください。
- 昔はLambdaでSecurity GroupのIPアドレスを定期的にメンテナンスしていました
- AWS WAFを利用して制限する方法が確立されました
- ALBのリクエストルーティングが実装されAWS WAFなしでもできるようになりました
Session4: Aqua Security Software Ltd. Teppei Fukudaさん「AWS Security Hubを使ってKubernetesクラスタへの脆弱なイメージのデプロイを防ぐ」
- KubeConで発表した内容をベースにしているのでコンテナの細かい説明をしていないのでご了承ください
- 脆弱性はめちゃくちゃ増えている
- 2019年は1万8千件を超えている
- 1日あたり47.4件のペース
- 脆弱性をちゃんと把握するのは大変
- 1個につき何時間もかかるので脆弱性のリリースペースに合わせるのは辛い
- Assetの管理は大切
- どのOS使っているのか、どの言語を使っているか
- 自社に影響ある脆弱性だけをチェックしていく
- 手動でフィルタリングする？
- コンテナはその内部にあるAssetを確認して、それと脆弱性情報を突き合わせるといい
- 脆弱性スキャナはいろいろある
- それらを使ってフィルターできる
- 1日あたり5-10件くらいに絞れる
- これは少ない？
- 脆弱性により危険度が違う
- CVSSスコアが高いものだけに絞るともっと減る
- そうすると1日0-1件になる
- これでOK？
- CVSSスコアは信頼できる？
- Heartbleedは5.0 Mediumだった
- 被害はたくさん出た
- CVSSスコアを付けている場所は複数ある
- それぞれでベクターが異なっている
- どのスコアを使うのがいいか
- 基本的にRedHatならRedHatが出しているものがいい
- CVSSについて
- 3つの評価基準
- 基本評価基準
- 現状評価基準
- 環境評価基準
- 本当はこれらをトータルで見る必要がある
- それぞれをどう使っているかによってもスコアが変わる
- CERT/CCからスコアの妥当性がないという指摘がでている
- これだけを使ってハンドリングするのは難しい
- 技術的な深刻度を表すもので自組織の場合どうかは別
- 3つの評価基準
- 自分たちのポリシーを作ることが大事
- 例えばbashの脆弱性
- 外に面するところでbashを使っていないから無視しよう
- 外部から侵入できなければ実行できないものなら無視など
- チャートを作っておく
- 当てはまるものは修正、それ以外はリスクを許容する
- 例えばbashの脆弱性
- ハンドリングするときに使う情報
- CVSS vector
- ネットワーク経由で攻撃できるのか
- 管理者じゃないとできないのか
- などなど
- CVSSスコアは8項目のトータル
- 組織においてはそれぞれの項目個別に見たほうがいい
- 完全性が重要なのか可用性が重要なのか
- 例えばATMなら物理的なアクセスも対策しないと
- CWE-ID
- XSSだよ、SQLiだよ、などと書いてある
- 階層構造になっている
- 上の方はジャンルになっている
- インジェクション系、など
- これらの情報からポリシーを作っていく
- CVSS vector
- チェックを機械的にやるために
- Open Policy Agent(OPA)が利用できる
- CNCFのプロジェクト
- ライブラリとして使うこともできる
- 外部サービスとしても利用できる
- RegoというDLSでポリシーを定義できる
- CVSSも全部信用していいわけではない
- 機械的に全部やるのは必ずしもいいわけではない
- コストと一緒に考える
- 集中すべき脆弱性にリソースを集中することが大事
- ここまでのまとめ
- ポリシーを決めて、OPAを使って自動化しよう
- 人間はその先を見よう
- Trivyと組み合わせてみる
- TrivyでOPAを統合できる
- Regoを渡してあげる
- 例
- もともと662件だったものが7件に
- 見るべきものを絞れる
- Trivy Enforcer
- AWS Security Hubを利用して管理できる
- Security Hubはセキュリティアラートを1箇所に集約できる
- ASFF形式を使う
- Trivyからも入れれる
- Trivyから脆弱性情報をSecurity Hubへ
- ポリシーを上げておく
- Trivy EnforcerがOPAを確認
- デプロイするイメージが危険なのかどうかをOPAに確認、Trivy Enforcerが止めることができる
- AWS Security Hubを利用して管理できる
- 開発のライフサイクルの様々な場所でTrivy + OPAで安全に保つことができる
- 共通のポリシーで管理できるのがいいところ
- デモ
- CVSS3がスコア7以上なら止める
- alpineをデプロイしてみる
- criticalな脆弱性があって失敗と出る
- ポリシーのスコアを9.0に変更
- デプロイ成功する
感想
脆弱性のトリアージのポリシーは非常に大事ですね。うまく自動化して運用負荷を軽減したいですね。
Session5: NRIネットコム株式会社 佐々木 拓郎さん、上野 史瑛さん 「対策本発売記念！AWS認定セキュリティ合格のコツ」
- AWS認定 セキュリティ- 専門知識の本を出してます
- AWSセキュリティのガイドブックとしても使えます
- 前後半に分かれてます
- ゴール
- AWSのセキュリティってこうやるんだよと人に説明できるようになる
- 説明するのが理解への近道
- AWSのセキュリティの考え方と認定試験
- ソリューションアーキテクトとの違い
- ソリューションアーキテクトはどのように作るか
- セキュリティ専門知識は作ったものの安全をどのように確保するのか
- 試験範囲と配点
- インフラストラクチャのセキュリティ
- ID及びアクセス管理
- データ保護
- の3つが重点項目
- AWSとセキュリティ
- 色々やることが多くてややこしいと思ったことありませんか？
- 全体像を把握するためにざっくりと分類してみましょう
- 巨人の方の上に立つ
- 1から全部自分で考えると大変
- フレームワークに乗って最小限の労力で
- まずは城跡を覚えて真似るところから
- NIST サイバーセキュリティフレームワーク(CSF)
- Wall-Architectedフレームワーク(W-A)
- この2つに目を通す
- NIST CSF
- 5つのコアとその下にサブカテゴリー
- IPAから日本語で出ているので読んでみるといい
- W-A
- 5つの柱
- 試験ではセキュリティと運用が効かれることが多い
- W-AもNIST CSFを参考にしている
- AWSのフレームワークに沿っているので考え方を理解できるといい
- 色々やることが多くてややこしいと思ったことありませんか？
- フレームワークに自分の環境を当てはめるとどうなるか見てみるといい
- そうすると理解していける
- 自分で設定していくと100倍理解が進む
- ソリューションアーキテクトとの違い
- AWSにおける3つのセキュリティ
- 重点強化領域の問題解説
- IAMを理解する
- 最小権限の話
- 回答にも実際のポリシーが書かれている
- つまり試験ではポリシーを理解している必要がある
- KMSを使った鍵管理と暗号化
- 経路の暗号化とのあわせ技も理解しておく
- S3とEBSのデータ保護
- データ保護と経路暗号化
- IAMを理解する
- 後半戦
- 話す内容
- セキュリティサービスについて
- 勉強方法
- 質問
- システム、AWS以外でセキュリティと聞いたら何を想像しますか？
- 鍵を想像した人はいますか？
- AWSにおいても鍵は重要
- 鍵の管理といえばKMS
- データの暗号化をする
- KMS自身を触ることは少ないのでは？
- 試験ではKMSの使い方が問われる
- 今回はKMSについて深堀り
- 鍵の管理といえばKMS
- 暗号化
- 暗号化とはもととなるデータを鍵データと組み合わせて特別な処理(アルゴリズム)を行い別のデータに変換すること
- 例: 元データと鍵データでランダムな文字列に変換
- エンベロープ暗号化
- データを暗号化する鍵(データキー)とデータキーを暗号化する鍵(マスターキー)を2段階で利用する暗号化方法
- KMSで使われている
- KMSではCDK(データを暗号化するためのキー)とCMK(データキーを暗号化するためのキー)を利用
- CMKは3種類
- カスタマー管理CMK
- AWS管理CMK
- AWS所有CMK(これはあんまり覚えなくていい)
- 利用者側で厳密に管理するならカスタマー管理CMKを利用する
- ローテーションの違いもある
- 続きは本で！
- 勉強の方法について
- 試験に受かりたければまず勉強
- 試験向けのおすすめの勉強法
- AWS提供の資料
- 試験準備コースがオススメ
- BlackBelt
- 公式ドキュメント
- 練習問題
- udemyなど
- AWSを触ってみる
- セルフスペースラボ
- ハンズオン資料
- チュートリアル
- 書籍
- いろいろ
- AWS提供の資料
- やる気がでないこともあるのでは
- こんな時間ないですか？
- テレビ、映画、ゲーム
- 通勤中
- ランチタイム
- これを勉強に変えたらいいのでは
- 暇があればスマホで見るなど
- こんな時間ないですか？
- 継続的に勉強するコツ
- 気合を入れすぎないでモチベーションが低くても勉強できるように(SNSやテレビを見るような気持ちで)
- スマホで気軽にドキュメント、PCでハンズオン
- 継続的に、知識が抜けるのを防ぐ
- 太く短く、しっかり集中する
- 1つのリソースだけで勉強しない、定着しやすい
- 不合格でも落ち込まない
- 読むのが苦痛であればおすすめしない、業務関連のものとかをやる
- さいごに
- まずは気軽に
- やりすぎ注意
感想
フレームワークの活用はめちゃくちゃ大事ですね。まずはフレームワークを見て考えていくのがいいでしょう。薄い本めちゃくちゃオススメなのでぜひ買いましょう！試験対策本もぜひ！
さいごに
勉強になるなぁという情報がいっぱいでした！今回はセキュリティの考え方の話が多かったですね！
FargateやLambdaのセキュリティもいろいろ考えるところはあるのでやっていきたいですね！
4
