この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第17回が開催されましたのでレポート致します。
Security-JAWS 【第17回】 勉強会 2020年5月29日(金) - Security-JAWS | Doorkeeper
レポート
Session0: アマゾン ウェブ サービス ジャパン株式会社 沼口 繁さん「本日のライブ配信環境ざっくりと」
- JAWSといえばオフラインだった
- 最初はセミナールームで
- 第2形態としてセミナールームを使ってAmazon Chimeを利用して配信
- 第3形態では人数制限を超えるためにTwitchを使った
- 2019年1月からはAWSJのエキスパートのオンライン配信をやっていた
- 第4形態OBS Studio + TwitchやYouTube Liveで配信
- 今回はWorkSpaces上で配信環境を整えている
- 記事にしている
Session1: アマゾン ウェブ サービス ジャパン株式会社 大松 宏之さん「アカウント作成後やること＋ちょっと慣れてきたら使えるセキュリティサービス」
- AWSアカウント作成したあとのセキュリティ対策についておさらい
- する前に、AWSのセキュリティ自体をおさらい
- AWSにとってのセキュリティは「クラウドセキュリティはAWSの最優先事項」
- セキュリティの考え方は責任共有モデル
- セキュリティはAWSと利用者の間で共有される
- 物理などはAWSが面倒見る
- 利用者は自分たちでデータなどの管理統制できる
- 詳しくはAWS コンプライアンスをみるとよく分かる
- データセンターがどうなっているかとかわかる
- 必要なサービス
- IDアクセス権管理
- 不要な権限が与えられると情報の流出や破壊などがある
- AWS IAM(Identity and Access Management)
- 認証認可の仕組み
- ユーザーは大きく二種類
- ルートユーザーとIAMユーザー
- 最初はルートユーザーのみ
- 日常的な作業にルートユーザーは利用しない
- IAMユーザーを利用して使用する
- AWS IAMのベストプラクティスを読むといい
- セキュリティイベントの重要な指針
- 今回紹介するもの以外にもパートナーツールや連絡先の設定(AWSからの連絡がある)も活用したほうがいい
- 請求データ
- セキュリティイベントの重要な指針の1つ
- 不正な利用がされたときなど高額な請求がでる
- 請求の確認方法
- AWS Budgets
- AWS Cost Explorer
- AWS Cost & Usage Report
- 操作履歴とリソース変更履歴の記録
- ログとモニタリング
- いつだれがどのリソースをどんなふうに操作してどんな結果になったのか、記録する必要がある
- AWS CloudTrail
- 行動履歴
- AWS Config
- 変更履歴
- コンプライアンスの準拠や運用管理などの負担を軽減できる
- 脅威検知
- 脅威インテリジェンスを利用した脅威検知
- Amazon GuardDutyを利用して検知する
- AWSのインフラから取れる情報を機械学習にかけて検知
- 自身のAWS環境に手を加えなくても検知できるメリットが有る
- 悪意のあるスキャンやインスタンス/アカウントへの脅威などを検知できる
- AWSが持っている脅威インテリジェンスを元に通知
- ベストプラクティスの確認
- 自分たちの設定がAWSのベストプラクティスに沿っているか心配などの課題がある
- AWS Trusted Advisor
- 最適化するための推奨ベストプラクティス
- 5つのカテゴリーの中にセキュリティも含まれている
- デフォルトで有効化されているが、サポートの契約状況によって見れるものが違う
- ビジネス以上が推奨
- IDアクセス権管理
- ちょっと慣れてきたら使えるセキュリティサービス
- 継続的なセキュリティ
- セキュリティ対策は実施した瞬間から危殆化していく
- 攻撃者のほうが速い
- リスクベースで考えてコストを最適にする
- 人間で追いかけるのは大変なのでリスクが高いところから
- セキュリティリスクの方程式
- 脅威 x 脆弱性 x 資産価値
- リスクの分析と可視化
- Amazon Inspector
- 脆弱性診断のサービス
- CVEやCISベンチマークに基づいたリスク評価
- Security Hub
- リスク分析ダッシュボード
- セキュリティ・コンプライアンスの可視化
- ダッシュボードでまとめて管理できる
- Macie
- 最近東京リージョンで使えるようになった
- 新しくなった
- 既存はMacie Classic
- 必要とされる背景
- 多くのデータが共有可能なリソースに分散して存在している
- 機微情報の定義が拡大している
- 監視のコストが増大している
- 概要
- 可視化と評価の提供
- S3のバケットの使用状況の分析
- 機微情報の検出
- バケットの中に個人情報やクレジットカード情報が入っていないか検知
- スケーラビリティと集中管理の両立
- Organizations対応
- カスタム定義も利用できる
- 自動化と対応の実行
- APIがあって自動化できる
- 可視化と評価の提供
- ユースケース
- データプライバシーとセキュリティのチェック
- 機微情報へのアクセス状況を確認
- 機微情報がどこにあるか確認
- データ移行して機微情報を検出して、どうやって管理していくか検討する
- データプライバシーとセキュリティのチェック
- 料金
- 月ごとのS3バケット数
- 機微情報の検出の量
- 30日の無料枠は機微情報の検出は別枠
- Amazon Inspector
- 継続的なセキュリティ
感想
最初に考えないといけないところはいろいろありますが、まずはこれらをチェックしていきたいですね！
1つずつチェックしていきましょう！
Session2: NRIネットコム株式会社 上野 史瑛さん「初心者でも大丈夫！AWSアカウント作成時のセキュリティ設定」
- AWS、安全に使用できていますか？
- AWSアカウントは作成した時点でセキュリティリスクが有る
- 開発・検証用途のAWSアカウントの場合でも乗っ取られて大量にリソースを作成されるというリスクも有る
- 可能な限り速くアカウントを保護することが大切です
- 作成した時点で最低限やっておくべきセキュリティ設定がある
- レベルを3段階に分類してみた
- MUSTだけでも意識してほしい
- ルートユーザーの保護(MUST)
- パスワードを強力にする
- MFA設定する
- コストの可視化も重要
- IAMユーザーの請求情報アクセス許可(MUST)
- IAMでも施灸情報を見る場合にはIAMアクセスのアクティブ化をルートユーザーから実施する
- 右上のマイアカウントから
- Cost Explorerの有効化(SHOULD)
- 日々のコストを見れる
- 予算及びアラートの設定(MUST)
- Budgets(予算)を使用して通知するようにする
- CloudWatchを使用した請求アラームでもOK
- サポートプランの検討(SHOULD)
- 本番環境はビジネス以上のプランを検討
- ルートユーザーのみ
- 管理者IAMユーザーの設定(MUST)
- すべての操作が可能な管理者用のIAMユーザーを作成
- AdministratorAccessのIAMポリシーを付与
- 必要に応じてMFA強制の設定を入れる
- 利用者ユーザーの設定(MUST)
- 管理者だけは良くない
- 例えばVPCとEC2のみ利用できるユーザーなどを作成する
- 必要最低限の権限のみにする
- 一番重要だが、一番難しい
- 試行錯誤しながら決めていくといい
- IAMのマニアックな本を読むといい
- セキュリティ・ガバナンスのサービス
- CloudTrailの証跡設定(MUST)
- 設定するとS3に証跡を残すことができる
- 料金も殆どかからないため実施する
- AthenaによるCloudTrail可視化(BETTER)
- Athenaを使用してSQLでログ検索が可能
- CloudTrailの画面から簡単にできる
- AWS Configの有効化(MUST)
- AWSリソースの設定変更履歴を保存できる
- Trailは誰がどのだが、Configはリソース視点
- Configルールの設定(BETTER)
- AWSリソースの設定がルールに準拠しているかチェック
- Trailが有効になっているか
- S3が公開されていないか
- などなど
- 自動修復もできる
- AWSリソースの設定がルールに準拠しているかチェック
- GuardDutyの有効化(MUST)
- 脅威を検知できる
- CloudTrail、VPC Flow Logs、DNS Logsをチェックしている
- GuardDutyの通知設定(BETTER)
- デフォルトでは通知が飛ばないためCloudWatchルールとSNSを使う
- あるいはChatbotを利用
- IAM Access Analyzer有効化(MUST)
- 外部と共有しているIAMやS3などを通知
- 無料！
- Security Hubの有効化(MUST)
- セキュリティ情報のダッシュボード
- 各種サービスの状況を一箇所で可視化
- コンプライアンスチェックのルールもある
- Security Hubの通知設定(BETTER)
- GuardDuty同様CloudWatchによる通知を行う
- すべて通知するとたくさん出るのでイベントパターンを設定して絞るといいかも
- 例えば重要度がHIGH、MIDIUMのみ
- あるいはGuardDutyのみなど
- Amazon Detective有効化(SHOULD)
- インシデントの調査をするサービス
- GuardDutyで検知したイベントなどを時系列などで可視化して調査
- 使用方法
- APIのFailed callsをクリックするとAPIの詳細情報が一覧で出てくる
- IPやエラーの情報などがわかる
- どのユーザーがどんな操作しているかがわかる
- CloudTrailの証跡設定(MUST)
- 設定作業はここまで
- お役立ち情報を紹介
- Macie
- S3の個人情報検知
- Personal Health Dashboard
- メンテナンス情報など連絡
- Trusted Advisor
- AWSアカウント内のベストプラクティス準拠を確認
- Well-Architected Tools
- ベストプラクティスの方法論
- コストについて
- 一例
- セキュリティ系のサービスが全体の3.8%程度だった
- 殆どのサービスはそんなにお金がかからないのでぜひ使っていくべき
- 一例
- 複数アカウントの場合にはCloudFormationやTerraformなどで設定するといい
- Macie
- 宣伝: 認定セキュリティ本が出ます(MUST)
- 7月にでます
感想
具体的な設定方法も紹介されていて大変参考になりますね！
MUSTのサービスは本当にMUSTなので私も全部有効化を推奨します！あとDetectiveは何かあったときの調査がすごい捗るので私はMUSTと言っておきます！
Session3: アマゾン ウェブ サービス ジャパン シニアエバンジェリスト 亀田治伸さん「AWS Transfer Family - SFTP, FTPS, and FTP どれを使えばいいの？セキュリティの観点から考察する」
- AWS Transfer Familyの使い分けの話
- 最初に結論
- SFTPがオススメ
- なんでかをセキュリティの観点で説明
- AWS Transfer Familyとは
- マネージドサービス
- S3へのデータ転送に既存のプロトコルを利用可能
- 従来はAPIやSnowball、Storage Gatewayなど
- SFTP / FTPS / FTPが利用できるようになった
- 最近名前が変わった
- 最初はTransfer for SFTPだった
- 2020/04にFTPS, FTPをサポートして名前が変わった
- 違い
- FTP
- RFC114で定義、RFC959でTCP/IP対応
- ファイル転送のプロトコル
- FTPS
- FTPのSSL(TLS)化
- RFC4127が最新
- SFTP
- SSHのFTPライクインターフェース
- SSH File Transfer Protocol(IETF)
- not Simple File Transfer Protocol
- FTP
- AWSサービスとしての違い
- FTP
- VPCのPrivate Only
- FTPS
- VPCでEIP付与可能(ACMで証明書発行)
- PassiveモードでありNLBやNAT Gateway連携は要検証
- 認証とデータ転送は別ポートを使う
- 大きめのネットワーク空間が必要
- SFTP
- VPC外、VPC両方あり
- VPC Endpointあり
- FTP
- SFTP vs FTPSどちらを使うべきか
- ネットワークの観点から
- 新規であればSFTP利用を推奨
- FTPSは複数ポート利用
- ファイアウォールでポート範囲が必要
- SFTPは単一ポート(22)で処理可能
- 既存アプリの用途であればマイグレーションコストと相談
- 新規であればSFTP利用を推奨
- 認証の観点から
- 新規構築であればSFTPを推奨
- SFTPは鍵認証が必須
- マネジメントコンソール上で管理可能
- FTPSのID/PWD認証は脆弱(キーロガー等)
- 新規構築であればSFTPを推奨
- ネットワークの観点から
- 脱線コラム: でも鍵もクライアントから漏れる
- その可能性はある
- 耐タンパ性外部デバイスで防御は可能
- パスワードは同じ or 似た文字列が転用されているケースが多い(人が設定する場合)
- パスワードの定期ローテーションが良くないとされる1つの理由
- (AWS Credentialはサービスによる乱数生成)
- 忘れるなかれ…同じ鍵を複数SSH環境で使うでない。
- その可能性はある
- どちらを使うべきか
- AWS利用ユースケースの観点から
- VPCの取り扱いによるがSFTP推奨
- ユーザーによってはVPC対応サービスのみが認められるケースが
- 金融機関などでそういうこともある
- VPC Endpointの取り扱いはそれぞれ
- VPC内部から足を生やす機能
- VPC内部からインターネットゲートウェイを経由せず、インターネットに出ないでSFTPのエンドポイントにアクセスできる
- VPCのパブリックサブネットに作成する方法とVPC Endpoint経由でアクセスする方法がある
- VPC内の場合は認証 + セキュリティグループを利用
- VPC外だと認証のみ
- でもS3もVPC Endpointからのアクセスにすると同じ様になっているのできちんと整理して考える
- S3がOKなのであればやはりSFTP
- VPC EndpointがNGなのであればまずはS3の取り扱いを整理しよう
- ユーザーによってはVPC対応サービスのみが認められるケースが
- VPCの取り扱いによるがSFTP推奨
- AWS利用ユースケースの観点から
感想
新しくFTPやFTPSにも対応しましたが、ちゃんとよく考えて採用しましょうという話でしたね。
クラウドに持っていく際に最低限SFTPにすることを検討してみてはいかがでしょうか？
Session4: 株式会社イエラエセキュリティ 寺岡良真（traoka)さん「自力で頑張ってみる AWS EC2 インスタンスのフォレンジック」
- AWSリアルガチ勢ではないのでご了承ください
- ちょっとした説明
- AWS EC2のHDD解析（フォレンジック）
- これを拡張した話
- ちょっとした説明
- フォレンジックは法科学の一種
- パソコンやサーバなどデジタルデバイスから証拠やインシデントの原因を調査
- 鑑識の役割
- インシデント対応との違い
- インシデント対応は消防活動
- フォレンジック調査は消化後の焼け跡から事故の原因な経緯を調査
- 最近では両者をあわせてDFIRという言葉を使う
- AWS環境のインシデント
- EC2が絡む案件が多い
- ほぼ100%かも
- サーバの改ざん
- マルウェア
- 情報漏えい
- マイニング
- 攻撃の踏み台
- 攻撃者としても従来の攻撃手法が使えるのでお手軽に目的を達成できる
- EC2とオンプレの調査の違い
- 保全という作業がある
- サーバの解析や調査部分はほぼ変わらない
- 保全は重要な手がかりが消える可能性があるため、それを防ぐためにコピーする作業のこと
- 参考資料
- EC2が絡む案件が多い
- 流れ
- 調査の目的方針内容を決める
- 調査対象のデータの保全
- 保全したデータを元に調査解析(元のデータはいじらない)
- 調査した結果のまとめ、報告
- インシデント対応の場合
- NISTのSP800-61
- 調査方法
- ファストフォレンジック
- ある程度の証跡の喪失リスクを許容する代わりに素早く情報を収集する
- 最近はデータ量が多いため、時間がかかるので
- 証跡は汚れる
- 従来のフォレンジック
- サーバをまるごと解析
- HDDの保全のため時間がかかる
- 削除されたファイルが復元できたりする
- 証跡は汚れにくい
- ファストフォレンジック
- 専用環境を作る
- 調査用のAWS環境を分けるのが一番オススメ
- 1アカウント内でも棲み分けはできるが、汚さないために分けたほうがいい
- 一緒にすると調査環境が侵害されている可能性もある
- 分けるとアクセス管理も単純化できる
- 調査・保全用のインスタンスを作る
- フォレンジック用インスタンスを作成
- Windows, Linuxそれぞれあるといい
- これらはVPCを独立したりSGで通信を制限したほうがいい
- 万が一マルウェアが暴発しても周りに影響を与えない
- ケースごとに使い捨てもあり
- 補足: 調査はローカル？AWS？
- どちらでもいい
- AWS上でやるメリットは保全用インスタンスで調査可能
- 金銭的なコストは増えるけどデータダウンロードの時間を削減できたりする
- 専用マシン用意も大変
- 自力でやってみる保全作業
- データの保全は重要な作業
- ミスすると調査のやり直しになる
- 順番消失しやすいものから
- メモリーはHDDより先
- 実際のケースではインスタンスのロールバックや停止がされているときもある
- フォレンジックとしてはこれらは辛い
- 保全の方法
- EC2のスナップショットを作成
- スナップショットの共有でフォレンジック用アカウントにわたす
- なるべくインシデント発生直後のものが望ましい
- 共有できたらボリュームを復元
- 調査用インスタンスにアタッチ
- ボリュームを読み込んでdcflddまたはddでイメージファイルを作成
- 書き込み防止の為Linuxで保全するのもあり
- ローカルで解析する場合にはscp等でダウンロード
- 自力で頑張って見る調査・解析
- メジャーな解析ツールは商用が多い
- ガチでやるなら購入しか無い
- フリーなら下記がいい
- FTK Imager
- Autopsy
- SANS SIFT workstation
- SOF-ELK
- フリーだとAutopsy使いやすい
- インジェストモジュールで削除ファイルの復旧が簡単
- サーバの調査は気合で見ていく必要がある
- キーワード検索ができる
- 改ざんテキストやIPなどで検索
- バツマークが削除されたファイル
- 復元して確認できる
- 復元には限度があるので注意
- ダーティワードや具体的な情報がない場合にタイムラインで日時ベースに洗い出せる
- インシデント周辺の期間でみるといい
- 調査解析は断片的な情報を集め、それらをつなぎ合わせていくイメージ
- アプローチはいろいろある
- 余談: XFSについて
- フリーのツールでは読めない事が多い
- 頑張ってマウントする必要がある
- まとめ
- 調査はけっこう大変だが明らかになっていくとパズルみたいで楽しい
- CloudWatchやGuardDutyなどと組み合わせて調査すると詳細に確認できる
- インシデントを100%防ぐのは困難なのでフォレンジックに挑戦してみてはいかがでしょうか？
感想
めちゃくちゃためになりますね！上述したブログも一緒に見るとより参考になると思います！
いざというときのために、準備したり勉強しておきましょう！
Session5: F5ネットワークスジャパン合同会社 クラウドソリューションアーキテクト 伊藤 悠紀夫さん 「どこまで使える? 新しいWAFaaS。AWS WAF, Managed rulesとの使い分け」
- テーマ: WAFの運用できてますか？
- WAFの効果
- 脆弱性を悪用した攻撃を検出
- 脆弱性を悪用した攻撃から防御
- 複数のウェブアプリケーションへの攻撃をまとめて防御
- IDS/IPSなどのレイヤーで防げないアプリケーションの攻撃への対策
- IPAのWAF読本も参照
- 情報セキュリティ10大脅威 from 2018 to 2020
- 新しくサプライチェーンの弱点を悪用した攻撃、インターネット上のサービスからの個人情報搾取が入っている
- AWSでのWAFとは？
- AWS WAF
- AWS WAF + Managed Rule
- 3rd Partyのベンダーのサービス
- AWS WAF
- インスタンスを作ることなく簡単にデプロイ
- 管理もマネージド
- 従量課金でコスパがいい
- 留意点
- きめ細かいルールチューニング
- すべてのパケットログ取得
- ユーザ定義のルールの運用
- AWS WAF + Managed Rule
- 上記のルールの運用などの問題を解決できる
- AWS標準やベンダールールを簡単に利用
- ルール運用を任せられる
- 従量課金でコスパがいい
- 留意点
- マーケットプレイスから別途購入が必要
- ルールはブラックボックス
- これらの運用
- CloudWatch + Athenaにて検知数やログ監視
- チューニングを実施
- ブロックモードへ移行し、定常的監視
- もう少し楽にしたいという話がよくある
- もっとシンプルに現状把握したい
- チューニングが面倒
- 脅威情報対策も取り入れたい
- 3rdパーティのWAF
- F5のWAFaaSがある
- Essential App Protectionという名前
- AWSの上に乗っている
- マーケットプレイスから利用できる
- セットアップ
- マーケットプレイスからSubscribe
- メールでURLが届く
- クラウド専用のポータル画面が出てくる
- ダッシュボードが表示される
- 右上から保護したいアプリケーションを登録
- サービスをALBで後悔している場合を想定して説明
- 保護対象のFQDNを登録
- どのリージョンで保護するか設定
- どのような対策をするか設定
- シグネチャや不正IPの対策など
- CNAMEが発行されるのでDNSに登録する
- 以降はWAFを経由してアプリケーションに通信する
- 脅威の可視化
- リアルタイムにデモ
- アタックシグネチャが適用されている
- Geo Locationの登録
- 特定の国の通信を除外できる
- ファイルタイプ
- 許可しないファイルもブロックできる
- ホワイトリスト/ブロックリスト
- 許可するメソッド
- DVWAでデモ
- SQLインジェクションをブロック
- カード番号をWAFでマスキング(レスポンスも保護できる!)
- ポータルでブロックした内容を確認
- 不正通信がすぐにダッシュボードに
- クリックしてどこからどこに飛んでいるかマップにのる
- 詳細のログへドリルダウン
- 重要度やパラメータを細かく表示
- フルログもパースして見やすく表示
- リアルタイムにデモ
- どのように使い分けるといいか
- AWS WAFで基本的な保護
- マネージドルールで高度な保護やCVE対策
- 運用を楽にしたくなったり、高度な保護をしたい場合にはF5のEssential App Protectを検討してみては？
- お値段はいかほど？
- 大体1エンドポイント2万円/月
- 特定のユーザーには6ヶ月無料
感想
よく分かる棲み分けの内容でした！AWS WAFでも出来ることはいっぱいありますが、より運用管理をやりやすくしたり、高度な保護がしたいときにはこれも検討するといいと思います！
Session6: 日本電信電話株式会社 宮本 国雄さん 「Serverless-Goatで学ぶサーバレス環境のセキュリティリスク」
- 背景知識
- サーバレス環境とは
- サーバがない環境、ではなくサーバを気にしなくていい環境
- AWSなどがホストしていてユーザーはアプリケーションだけ管理
- ほとんどクラウドに任せられる
- Serverless-Goat
- OWASPが提供しているサーバーレス環境のやられ環境
- サーバーレスに詳しくなくても簡単にデプロイしてハンズオン可能
- やられ環境なので注意事項はよく読むこと
- セキュリティリスクTop10がある
- サーバレス環境とは
- 目的
- セキュリティリスクTop10のリスクをつく攻撃を行う
- 今回はちょっと拡張している
- ログに寄る攻撃の検知可否を確認する
- セキュリティリスクTop10のリスクをつく攻撃を行う
- 概要
- Serverless-GoatはTop10のうち7個のリスクが含まれている
- 残り3つを含めるために拡張した
- 動作概要
- トップ画面が表示される(Lambda)
- WordファイルのURLを入力してSubmit
- 外部からLambdaがファイルを落としてS3保存、Dynamoに情報記録
- S3にファイルサイズを追記(拡張)
- ブラウザにテキストファイルの中身が表示される
- セキュリティリスクをつく攻撃
- 今回SAS-05とSAS-06な対象外
- 実験
- 取得可能なログ
- API Gatewayのログ
- Lambdaログ
- S3アクセスログ
- 攻撃検知可否に関する検討
- 1. 関数実行エラー次のメッセージ漏洩
- クエリリストリングが空のリクエストを送信するとエラーメッセージ
- API Gatewayの設定不備
- エラーメッセージを返してしまう
- Stack Traceが表示されてしまう
- API GatewayのログとLambdaの実行ログが見れる
- 検知の検討
- ログでも検知できる
- 攻撃のパラメータが空で記録
- レスポンスボディにエラーメッセージが入っている
- クエリリストリングが空のリクエストを送信するとエラーメッセージ
- 2. 関数の環境変数への不正アクセス
- 攻撃コード(env)を含んだリクエスト
- サニタイズしないで関数に渡している
- 環境変数を秘密管理情報サービスに保存せずに利用している
- Lambdaの環境変数がすべて出ている
- クレデンシャル情報もでる
- 検知可否の検討
- API Gatewayのログで検知可能
- 3. DynamoDBへの不正アクセス
- クエリストリングにコマンドを挿入して取得
- 関数イベントデータインジェクション
- 不正な権限設定
- Lambdaに不要な権限の設定
- DynamoDBの保存データが閲覧
- 検知可否の検討
- API Gatewayのクエリのログに残っている
- 検知可能
- 4. Dos攻撃
- Lambdaの同時実行数制限を超えてアクセスする
- 通常のサーバと同様にDoSされる
- 検知可否の検討
- サービス輻輳と区別できない
- ログからは検知不可
- 既存のDoS検知技術を用いることで検知可能
- 5. 関数フロー操作攻撃
- S3パブリックアクセスによる想定していない手順で関数実行
- 直接S3にファイルをアップロード
- 検知可否
- S3のアクセスログから検知可能
- 認証タイプが
-になる
- 取得可能なログ
- 実験まとめ
- ログを取得しておくことで攻撃の検知は可能
- 独自実装環境での実験
- SAS-06を検証するために環境を準備した
- numpyの脆弱性をつくことにした
- 動作概要
- ユーザがpickleファイルをアップロード
- その内容をユーザが見る
- 取得可能なログ
- API Gateway
- Lambda
- S3
- numpyの脆弱性をつく攻撃
- whoamiの実行コマンドを保存させた
- ユーザ名が見れた
- 検知可否の検討
- API Gatewayの実行ログに保存されている
- Binaryだったが攻撃結果を出力したファイルが出力されたことを確認できる
- まとめ
- サーバレス環境でもセキュリティリスクはある
- 従来と同じようにDoSのリスクが有る
- 設定ミスのリスクがある
- Lambdaのクレデンシャルが盗まれる可能性がある
- Lambdaのサードパーティーモジュールの脆弱性があるリスクが有る
- セキュリティリスクTop10の攻撃検知可否を検討した
- ログを取得することで多くの攻撃検知が可能
- サーバレス環境でもセキュリティリスクはある
- 参考: セキュリティリスクTop12
- CSAが2019年に発行
- 2つ追加されている
- 不要な関数、クラウドリソースのイベントトリガー
- 相互実行データの永続性
- /tmpを削除しないことにより情報流出する
感想
サーバレス環境でもセキュリティリスクがあるので適切に設定したりする必要がありますね。ログを取ったりもそうですし、WAFを置いたりCloudWatchの監視も合わせて検討したいですね。
さいごに
初心者向けからガッツリ深い話までありました！
基本的な対策はきちんとやりつつ、徐々に上の話も検討していけるといいですね。
また、サードパーティーを使ったり、フォレンジックなんかはプロフェッショナルに依頼するのも検討していきましょう。餅は餅屋！
12
