こんにちは、臼田です。
Security JAWS 第33回が開催されましたのでレポート致します。
Security-JAWS【第33回】 勉強会 2024年5月23日(木) - Security-JAWS | Doorkeeper
動画
後ほど
レポート
Session1: APIGWとLambdaで決済APIをPCIDSSに準拠したお話 株式会社ゆめみ 砂岡 雪さん
- そもそもPCI DSSとは？
- クレジットカード決済におけるクレジット会員データを安全に扱うことを目的としたセキュリティ基準
- 12個の要件と6個の目的に準拠する必要がある
- なぜAPIGWとLambdaでPCI DSSに準拠することになったのか
- 既存の環境
- コストが高い
- 通信経路が分かりづらい
- 低コストにしてわかりやすくしたい
- 管理VPC郡とサービスVPC郡がある
- コストは管理VPC郡に偏っていた
- VPC PeeringしてPeering先からインターネットに出たりするなど経路制御がある
- APIで画面がいらない仕様
- Lambdaに加えてWAFやRDSなどを使う
- サービスVPCの中にRDSだけは残した
- 管理VPCにVPC Lambdaを作った
- API Gatewayから入ってくる
- ログはCloudWatch
- CloudFrontも入れてこれもログを取りWAFで防御
- LambdaのSecurity GroupはアウトバウンドでRDSと決済代行会社のみにしている
- 既存の環境
- 満たしたセキュリティ要件
- PCI DSSの対象環境は決済システムVPCのみ
- RDSは対象外
- WAFでOWASP Top10対応やNISTなど
- ログはCloudWatch Logsへ
- 発生した問題
- 一部加盟店に提供していた決済用画面が利用できなくなった
- 無いと言われていたが実はあった
- CloudFront + S3で対応した
- WAFがPOST通信をデフォルトで拒否
- 拒否したルールを検知モードに変更した
- マネジメントコンソールへのログインがPCI DSSの対象になった
- 代替コントロールとしてCloudTrailの監視ログでCloudWatchに流して、6回ミスをしたら通知するように設定した
- 一部加盟店に提供していた決済用画面が利用できなくなった
- WAFで使ったルール
- SQL database
- Bot Control
- Admin Protection
- Core rule set
- 他にもいくつかカスタマイズ
- リプレースして楽になったこと
- インフラの大部分をフルマネージドにできた
- AWS Artifactで説明をカバー
- インフラの展開がIaCでできるように
- コードレビューできる
- 定期スキャニングの対象が開発コードのみになった
- 4半期に1度のネットワーク層の脆弱性スキャンが免除になった
- 仕様書などの作成資料が大幅に減った
- 用意すべき監査資料がなくなった
- インフラの大部分をフルマネージドにできた
感想
VPCの構成要素を減らしてPCI DSSの監査負荷を減らしたり、費用を削減できるのはいいことですね！真似したいですね。
Session2: イノベーションを加速するためのGRCとAWSセキュリティ アマゾン ウェブ サービス ジャパン 合同会社 執行役員 パブリックセクター技術統括本部長 瀧澤 与一さん
アーカイブ無しです！
Session3: Amazon Cognitoでのパスキー（パスワードレス認証）実装 メドレー keikoitさん
資料はこちら
- パスキー認証とは
- パスワードを利用しない認証方式
- WebAuthnとCTAP
- 認証器はFIDOなどで決められている
- パスキー認証の3つの特徴
- 公開鍵暗号方式
- 最近は認証器をなくしても、クラウドバックアップから復旧ができるなどの仕組みが出てきている
- チャレンジレスポンス
- 認証器がRPサーバーの識別子に対して署名
- 中間者攻撃などに耐性がある
- 公開鍵暗号方式
- NIST SP 800-63Bへの補足
- パスキーに関する補足文章がでた
- 今までは外に出ないからAAL2を満たす感じだった
- クラウドプロバイダが攻撃されたらどうなるかなどの脅威についても書かれている
- AWS公式からCognitoでハンズオンがある
- Implement Passwordless authentication with Amazon Cognito and WebAuthn
- Amazon Cognito Passwordless Auth
- カスタム認証フローでLambdaがいろいろやる
- チャレンジと検証をするLambda関数がある
- 手順
- サンプルコードを使う場合非常にかんたん
- 1-2時間かからない
- デモ
- ユーザーIDを手入力してもいいし、ボタンを押すだけにもできる
- ボタンを押してサインインする
- パスキーが2つ登録されているのでそれを選択するようになる
- Macで確認しているが、今回はiPhoneを利用して認証する
- QRコードが表示されて、これをiPhoneでスキャンする
- 入れた
- DynamoDBに最後にいつサインインしたかやパスキーの情報などが保管されている
- 認証方法
- メインはパスキー
- フォールバック用でMagic Linkになっている
- 他にも一般的にはパスワードを許す場合がある
- しかしフォールバックが脆弱性になることがあるのでパスキーオンリーにしていきたいところだが、ハードルは高い
- シーケンス
- リクエストをブラウザ経由でRPサーバーへ
- チャレンジをブラウザに
- 本人確認後認証器で鍵を作成してレスポンス
- サーバーで検証して公開鍵などをDBに保管
- Cognitoでやると
- API Gatewayが呼び出されてJWTの検証がされる
- 裏のLambdaで検証してデータをDynamoDBに保管する
- Cognitoからはカスタム認証のLambdaを呼び出す
- DynamoDBの中身
- aaguid: パスキープロバイダーのID
- 野良のものを管理しないといけないので最近はこれの認証プログラムがFIDOで検討されている
- flagBackupState
- クラウド上にバックアップされているかどうか
- aaguid: パスキープロバイダーのID
感想
パスキーいいですね。ワークショップもあってかんたんに試せるのでガンガン使っていきまっしょい！
Session4: Secure Serverless Architecture Fusic 技術本部/技術共創部門 清家史郎 (@seike460)さん
- サーバーレスアーキテクチャの利点と課題
- サーバレスとはなんなのか
- CNCFによるとサーバー管理を必要としないやつ
- 利点
- スケーラビリティとかいろいろあるよね
- 課題
- セキュリティの複雑性
- トラブルシューティングの難しさ
- 依存関係の管理
- コールドスタート
- ベストプラクティスの進化
- 特に上2つに今回は向き合う
- セキュリティの重要性
- 大事だよね
- 企業の信頼を損ねたりビジネスできなくなる
- セキュリティ対策のアプローチ
- 予防
- 起こらないようにする
- 検知
- なにか起きてもすぐに検知する
- 対応
- 復旧
- 予防
- 対象サービス
- API Gateway
- Lambda
- CloudFront
- S3
- DynamoDB
- API Gateway / Lambdaのセキュリティ
- API Gateway
- リクエストの入口に注目
- 入口からバックエンドに行けなければ攻撃は成功しない
- 認証認可
- API KEY認証
- クライアントが信用できる場合のみ有効
- 漏洩すると弱い
- パブリックに公開されたHTMLやJavaScriptなどへの埋め込みはNG
- クライアントが信用できる場合のみ有効
- IAM認証
- セキュアな場所に配置したアクセスキーを利用
- パブリックNG
- ローテーションも検討したほうがいい
- AWS Sigv4を利用する
- バックエンドに配置するのが一般的
- Cognitoユーザープール
- フロントで使うならこれ
- ユーザープールを使用してJWTトークンを発行
- JWTを検証してIAM認証する
- API KEY認証
- トラフィック保護
- WAFの導入
- レート制限とスロットリング
- ネットワークセキュリティ
- VPCリンク
- API GatewayからVPCにアクセスする
- VPCエンドポイント
- VPCエンドポイントからVPCにアクセス
- VPCリンク
- Lambdaのセキュリティ
- 入口を守るだけではだめ
- ここもしっかり守る
- IAMの最小権限を意識する
- 権限設定(IAMロール)
- 必要最低限の権限の付与
- S3バケットへの読み取り権限のみを渡すなど
- 環境変数の管理
- KMSによる暗号化
- AWS Secrets Managerの利用
- RDSへの接続情報などはここから利用
- VPC設定とセキュリティグループ
- VPC Lambdaでプライベートリソースへのアクセスを提供
- RDSに接続したい場合など
- コールドスタートとIP数に注意
- セキュリティグループのベストプラクティス
- 最小限のアクセスを許可するポリシー設定
- VPCの通常の運用と同様
- VPC Lambdaでプライベートリソースへのアクセスを提供
- API Gateway
- CloudFront / S3のセキュリティ
- CloudFrontのセキュリティ
- オリジンになることが多いS3をどう保護するのか
- 一番前に立つことになるのでAWS WAFなどで守ることを視野に入れる
- オリジンサーバーの保護
- OAI
- 署名付きURL及び署名付きクッキー
- OAI
- HTTPS
- 証明書を適用する
- WAFの設定
- S3のセキュリティ
- S3のアクセスコントロールを適切にする
- 公開されるHTMLなどに絶対にあくせすきーなどを置かない
- バケットポリシー
- アクセス制御する
- サーバーサイド暗号化
- SSE-S3
- SSE-KMS
- SSE-C
- ネットワークアクセス制御
- VPCエンドポイントを利用した限定的なアクセス
- パブリックアクセスブロック
- CloudTrailによる監査ログ
- ログの監視とアラート
- CloudFrontのセキュリティ
- DynamoDBのセキュリティ
- データ保護
- サーバーサイド暗号化
- アクセス制御
- IAMで最小権限
- CRUDの細かい権限管理を適用する
- IAMロールを利用する
- IAMで最小権限
- ネットワークセキュリティ
- VPCからアクセスするならVPCエンドポイントを利用する
- ログとモニタリング
- CloudWatchとCloudTrailを使う
- メトリクス、ログ、アラームを活用する
- CloudWatchとCloudTrailを使う
- データ保護
- まとめ
- サーバレスになったからセキュリティが上がるわけではない、複雑性は上がる
- 入口を守ることは大事
- どんな属性のものをナンの目的でどこにどのように配置するのかを理解する
- セキュアな運用のためにVPCの利用も検討する
感想
サーバレスを利用してるとコンポーネントが増えて複雑になるので、セキュリティ対策が大変になるということはままありますよね。セキュリティの原則や考え方はいつもかわらないので、理解してやっていきましょう。
Session5: 左手は添えるだけ！？AWS Well-Architected Frameworkが教えてくれる大事なデータの守り方 日本電気株式会社 クラウド・マネージドサービス事業部門 大竹孝昌さん
- AWSセキュリティわかる？難しい？
- アーキテクチャ設計において大事なデータの守り方を紹介
- AWS Well-Architected Frameworkとは
- これ
- ベストプラクティス集
- 6つの柱
- 本当か？
- 個人的にはベストプラクティス集ではない
- 質問に対するベストプラクティスが色々書かれている
- しかしリスクに対するあんなやり方がありますと書いてある
- リスク評価の質問集だと思う
- 詳しくはJAWS DAYS 2022の動画で
- データを守るベスト・オブ・ベストプラクティス
- 実は期待しているベストプラクティスは付録に入っている
- SEC08-BP05 人をデータから遠ざけるメカニズムを使用する
- データの閲覧や操作をスクリプトやダッシュボードなど間接的なデータアクセスを実現すること
- 文面を素直に理解するとこの程度だが解釈を工夫する
- ベストプラクティスは解釈次第で化ける
- まずは守るデータがどこにあるのか把握
- どのサービスがデータを保持するのか？
- サービスが守り方を決める
- よくあるデータ保存場所
- DB
- ファイル
- VPC内
- VPC外
- サービスへのアクセス経路によっても守り方は変わる
- どのサービスがデータを保持するのか？
- 人をデータから遠ざける
- 経路を絞る
- データソースへのアクセス経路を限定する
- VPC内ではEC2インスタンスにアタッチされたENIにセキュリティグループがアタッチされる
- EFSやRDSにもセキュリティグループがアタッチされる
- セキュリティグループのID同士で紐づけてルールを記述する
- ルートテーブルでも絞る
- データソースへのアクセス経路を限定する
- 権限を絞る
- 人やプログラムごとにアクセス可能範囲を定義する
- アクセスできるのか
- アクセスできてもどのリソースにさわれるのか
- 認証と認可の管理方法はサービスごと異なる
- RDSだと認証はIAMでもできるが認可はDB側の機能
- 最近はAmazon Verified Permissionsをアプリケーションの認可に利用できる
- バックアプデータのアクセス制御も本番データと同じようにする
- DBのスナップショットがみんなさわれるのはだめ
- 詳細はAWSのガイド(1次情報)を参考にしよう
- 人やプログラムごとにアクセス可能範囲を定義する
- 手段を絞る
- データの閲覧や操作をツール経由に制限する
- 踏み台サーバー経由とか
- ログイン直後に自動でスクリプトが立ち上がるようにして操作を制限する
- マネジメントコンソールからDynamoDBやS3の中身を見れたり
- QuickSightからしかデータを見れないようにしたり
- データアクセスのIAMを利用した時にアラートを出すなどもよし
- 踏み台サーバー経由とか
- データの閲覧や操作をツール経由に制限する
- 経路を絞る
- 誰がそのデータにアクセスしているか意識する
- 人やプログラムがデータにアクセスする
- 仕組みを分解すると結局データにアクセスするのはアプリケーションなどのプログラム
- 人をデータから遠ざけた後
- 痕跡を残す
- 必要なものはすべて記録せよ
- 誰がどこに残すのかを意識せよ
- アクセスする側で残す
- データストア側で残す
- RDSならRDS自身で記録できる
- CloudTrailで操作のログが記録される
- 自分たちの実装は自分たちでログを保存
- 誰がどこに残すのかを意識せよ
- 必要なものはすべて記録せよ
- 検知と通知
- すぐに気づきたいものを選別してアラートを設定
- EventBridge経由でSNS通知やLambdaでカスタムアクションなど
- 定期的なログ確認
- 監査が必要
- 改善していく
- なんとなく確認は意味がないので具体的なチェック観点を用意する
- チェックリストは有効性もあるけどチェックリストのことだけしかやらなくなったりする
- 使い手次第
- 痕跡を残す
- まとめ
- アーキテクチャ設計編
- 経路を絞る
- 権限を絞る
- 手段を絞る
- 証跡を取る
- システム運用編
- 定期的なログ確認
- 設計や運用の改善
- アーキテクチャ設計編
感想
分解していくとよく理解できますね。しっかりやっていきましょう！
Session6: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー
EOL管理とかが流行ってますが、EOLが問題というよりは脆弱性が放置されているのが問題なんだと思う。EOLすぎたけど新しい脆弱性がないって場合のリスクは、新しい脆弱性が報告された時に、対応できない（しにくい）という認識で良いですか？
- 脆弱性にフォーカスした質問だが、そもそもEOLになるとその仕組みが周りに影響がある
- 周りのアップデートを妨げたり
- EOLしたものは置き換える必要がある
- そもそもEOLしているものを抱えること自体がリスク
- サポートも受けられない
Security HubやAWS Configとかで権限が強すぎるとかSGがガバガバすぎるのを、数十のアカウントに対してスキャンして結果を確認するのが辛いんですが、その辺を楽にできるツールなりSaaSとかってどんなのがありますか？
- 対応していくうえで再度出てくることを防止する必要がある
- 作り変えていく
- そもそもこれが辛くなるなら会社の仕組みを変える必要がある
- ガイドラインやルールを整備する
- 現場への教育をする
- 現場にセキュリティの責任をもたせる
- これを徹底して回すと辛くないはず
- そうなるとツールは何でもいい
- SREに全部の責任が押し付けられるのは違う
- この問題はCSPMなどサードパーティのツールを入れるだけでは解決しない
- 検出タイミングも遅い
- 開発段階でそれを検出して直せるようにしていく必要がある
円安の影響で上層部から更なるコスト最適化を求められている中、新しいセキュリティサービス機能が追加されても、OKしてもらいにくくなってます。コストかけたくない、でも それなりに セキュアでありたい という上層部の希望をどうやって実現させていくか、線引きがムズイです。こと細かく、この時は防御できるけど、この場合はダメみたいな話をしても、どこまで分かってもらえているのかも微妙で、、、似たような状況の方は多いと思うのですが、皆さん、どのような 心持ちで日々対応されているのでしょうか？
- セキュリティ以外のコストを削ろう！
- エンドポイント系を整えるだけでも安くなる
- コストの具体的な試算をしてリスクと天秤にかける
- リスクの分析がされている必要がある
- 経営者が理解できるリスクとお金の話をする
- 過去に事故対応をしたりしていたら、その時の費用や時間を説明に使える
さいごに
今回もいろんなセキュリティの知見が集まりましたね。セキュリティ対策を諦めない！
5
