概要
AWS SUMMIT ONLINEのうち、セキュリティ関連セッションをまとめました。
(基本的には、資料からの抜粋ですが、サマリに関しては内容を変更しています)
視聴前・視聴後のご参考になれば幸いです。
なお、AWS Summit Online 2021 は 5/31 までオンデマンドで公開中です。
(各セッションの資料も DL 可です)
また、アンケートに回答することで 25 USD の AWS クレジットを獲得できます。お忘れなく。
内容
【基本の AWS サービス】ユーザーエクスペリエンスとセキュリティを最適化する AWS エッジネットワークサービス(AWS-33)
Link: 【基本の AWS サービス】ユーザーエクスペリエンスとセキュリティを最適化する AWS エッジネットワークサービス(AWS-33) - Summits JP Production
視聴対象者
- 顧客向けアプリケーションの構築や AWS への移⾏を検討している IT 部⾨の意思決定者や開発者の⽅
- AWS エッジネットワークの各サービスの基本を理解したい⽅
ゴール
- ユーザー体験とアプリケーションのセキュリティ向上に AWS エッジネットワークサービスがどのように役⽴つかを理解できるようになる
- アプリケーションをグローバルに展開するのに役⽴つ主な AWS エッジネットワークサービス・機能を活⽤できるようになる
まとめ
- AWS エッジネットワークサービスはインターネットの課題 (可⽤性, 安定性, 性能)
を解決するために AWS グローバルネットワークを有効活⽤したサービス
- ⽇本国内のみ、⼩規模なユースケースでも利⽤可能
- パフォーマンス: Amazon Route 53, Amazon CloudFront, AWS Global Accelerator
を適切に組み合わせることで様々なサイト, サービス, API に適⽤可能
- セキュリティ: Amazon CloudFront のアクセス制御, 暗号化接続機能, AWS Shield,
AWS WAF などの AWS セキュリティサービスと連携
- カスタマイズ: Lambda@Edge により柔軟な処理を実⾏可能
- イノベーション: パフォーマンスとセキュリティに関連する機能を継続的に追加
- コスト最適化: オンデマンド, キャパシティ予約, 料⾦クラスを活⽤
サマリ
- AWS グローバルネットワーク を利⽤し、より⾼速で安定したユーザ体験を提供
CloudFront のキャッシュも有効活⽤
-
Amazon CloudFront
-
Amazon CloudFront Lambda@Edge
- エッジのイベント駆動型コード
- タイミング
- ビューワーリクエスト / レスポンス
- オリジンリクエスト / レスポンス
- カスタマイズ
- レスポンス Header の操作
- 認証
- HTTP リダイレクト
- A/B テスト
- スマートコンテンツアセンブリ
- 画像の最適化
- アクセス制御
-
CloudFront コスト最適化
-
AWS Shield Standard / AWS Shield Advanced
- マネージド型の分散サービス妨害 (DDoS) に対する保護
-
AWS WAF（ウェブアプリケーションファイアウォール）| AWS
- ウェブアプリケーションファイアウォール
- WEB アプリケーションの脆弱性を悪⽤した攻撃から WEB アプリケーションを保護
- 悪意のあるリクエストのブロック
- カスタムルールに基づいた Web トラフィックのフィルター
- モニタリングとチューニング
-
Amazon Route 53
-
AWS Global Accelerator（アプリケーションの可用性とパフォーマンスを向上）| AWS
- AWS グローバルネットワークを使⽤し、アプリケーションのグローバルな可⽤性とパフォーマンスを向上
- レイテンシーの影響を受けやすいアプリケーションを高速化
- 簡素化したグローバル規模でのトラフィック管理
- 回復性と可用性を向上する
- アプリケーションを保護する
入門！ AWS アイデンティティサービス
Link:【基本の AWS サービス】入門！ AWS アイデンティティサービス(AWS-37) - Summits JP Production
視聴対象者
- AWS の基本的な概念は知っている方
- １つの AWS アカウントで利用しているが、だんだん管理が難しくなってきたと感じている方
- 組織での AWS の利用を検討している方
ゴール
- AWS のアイデンティティサービスで出来ることを知る
- 効率的なアクセス権限の管理方法
- マルチアカウントのメリットと、その実現方法
- 最小権限の原則にそったアクセス権限のアプローチ
まとめ
- AWS のアイデンティティ
- マルチアカウント環境でのアイデンティティ管理
- マルチアカウントのメリット
- AWS Organizations、AWS SSO などで簡単に構築
- 最小権限を実現するためのテクニック
AWS アイデンティティサービスで効率的で安全なアクセス権限の管理を！
サマリ
- AWS のアイデンティティ
- アイデンティティの３つの基本要素
-
Who can access What
- AWS のアクセス管理
- アイデンティティベースポリシー
- リソースベースポリシー
- タグベースのポリシー
- マルチアカウント環境でのアイデンティティ管理
- AWS アカウントとは
- 課金の分離単位
- AWS 環境の分割単位、リソース管理の枠組み
- サービスクォータ(サービス制限)の単位
- セキュリティの境界
- マルチアカウントを用いるメリット
- Ref. AWS におけるマルチアカウント管理の手法とベストプラクティス
- ガバナンス
- 課金
- リソースの操作権限を特定の事業部に委譲し、その中でより自由に AWS プラットフォームを活用
- 組織
- 課金に関する可視性、責任、及びアカウントごとのコントロール
- 運用
- 構成変更時の影響範囲を小さくし、他の組織を気にすることなく自身固有の環境を利用
- AWS Organizations
- 複数の AWS アカウントを 1 つの組織に統合できるマネージドサービス
- AWS アカウントとリソースの集中プロビジョニング
- 一括請求によるコスト最適化(ボリューム割引、RI ブレンドレート)
- セキュリティの一元管理とコンプライアンス準拠
- AWS Single Sign-On
- AWS アカウントとビジネスアプリケーションへの SSO を提供
- AWS Control Tower
- ベストプラクティスにそった AWS マルチアカウント環境を簡単にセットアップ
- Control Tower のガードレール
- 必須のガードレール
- Control Tower を正常に稼働させるために必要な禁止事項を SCP で定義したもの
- ログ保存や構成監視を停止させない実装など
- 推奨されるガードレール
- マルチアカウントのベストプラクティスに基づく制限事項
- SCP の例：root ユーザでアクセスキーを作らない、root ユーザで操作しないなど
- Config Rules の例：EBS ボリュームの暗号化、S3 のパブリック読み書き禁止など
- 選択的ガードレール
- AWS エンタープライズ環境で一般的に利用されている制限事項
- SCP の例：MFA なしの S3 バケット削除禁止、S3 バケットのクロスリージョンレプリカ禁止など
- Config Rules の例：MFA なしの IAM ユーザアクセス禁止、バージョニングのない S3 の禁止など
- 最小権限を実現するためのテクニック
- IAM のアクセスアドバイザーで各 AWS サービスの最終利用時間をチェック
- 必要ないことを確認後、アクセス権限を削除する
AWS におけるネットワーク＆アプリケーション保護のすすめ(AWS-38)
Link: AWS におけるネットワーク＆アプリケーション保護のすすめ(AWS-38) - Summits JP Production
視聴対象者
スタートアップからエンタープライズまで、AWS のセキュリティアーキテクチャに関わる⽅
まとめ
- AWS の境界防御サービスの概要
- AWS Network Firewall
- AWS WAF
- AWS Shield Advanced
- アプリケーションの要件に応じた設計の勘所
- ⼀般的な Web アプリケーション
- 遅延にシビアなアプリケーション
- サーバーレスアプリケーション
- オンプレミスアプリケーション
- 統制と運⽤をスケールさせる⽅法
サマリ
- AWS の境界防御サービスの概要
- Ref. Take action on your security & compliance alerts with AWS Security Hub - SEC201 - Chicago AWS Summit
- 境界防御サービス
-
AWS Network Firewall – アマゾン ウェブ サービス
- 特徴
- きめ細かい制御による柔軟な保護
- VPC とアカウントにわたり⼀貫したポリシー管理
- ⾼可⽤性のマネージド型インフラストラクチャ
- 機能
- パケットフィルタリング
- 既存のネットワーク ACL、セキュリティグループで対応できなかった部分
- 可視性とレポーティング
- ⼀元管理
- テクニカルユースケース
- インターネットからのトラフィックをフィルタリング
- アウトバウンドトラフィックをフィルタリング
- VPC から VPC へのトラフィックを検査
- AWS Direct Connect と VPN のトラフィックを保護
- デザインパターン
- 分散型セキュリティインスペクション
- 中央集中型セキュリティインスペクション
- 従来の機能との⽐較
- 通信ペイロードの検査が可能
- FQDN ベースフィルタが可能
- ルートテーブルにて、通信がファイアウォールエンドポイントを通るように構成
- 追加コストあり
-
AWS WAF（ウェブアプリケーションファイアウォール）| AWS
- 特徴
- 既存構成への影響なし
- 既存のアーキテクチャを変更せずに展開し、TLS / SSL または DNS を構成する必要はありません
- 簡単なデプロイとメンテナンス
- AWS および AWSMarketplace のマネージドルール、すぐに使⽤できる CloudFormation テンプレート、組み込みの SQLi / XSS 検出
- 柔軟にカスタマイズ可能なセキュリティ
- 1 ミリ秒の遅延で着信要求の任意の部分を検査できる⾮常に柔軟なルールエンジン
- サードパーティのルールは取り込むだけ
- AWS WAF コンソール内で、AWS Marketplace にピボットして、業界をリードするセキュリティベンダールールを選択して AWS WAF に取り込むことが可能
- AWS マネージドルール for AWS WAF
- ⼀般的な攻撃ベクトルと脅威をカバー
- SRT † によるキュレーションおよび保守
- OWASP ‡ TOP 10 よりインフルエンスを受けて開発
- 追加料⾦なし
- AWS WAF に備わるボット緩和
- AWS Shield Standard / Advanced
- ⾃動化されたインテリジェントな検出による緩和
- 独⾃の検出エンジンおよび緩和システムは、侵⼊のすべてのポイントで AWS を保護
- 既知のイベントやボリューメトリック異常をブロックするための機械学習技術の広範な使⽤
- トラフィックシェーピングは、最も疑わしいトラフィックを徐々にドロップし、誤遮断（False Positive)を抑制
- アラートと軽減策がコンソールに表⽰され、シグナルが CloudWatch にプッシュ
- アプリケーションの要件に応じた設計の勘所
- ⼀般的な Web アプリケーションの保護
- サーバーレスアプリケーションの保護
- 遅延にセンシティブなアプリケーションの保護
- オンプレミスアプリケーションの保護
- 統制と運⽤をスケールさせる⽅法
AWS 環境における脅威検知と対応(AWS-39)
Link: AWS 環境における脅威検知と対応(AWS-39) - Summits JP Production
視聴対象者
- アマゾンウェブサービス (AWS) 環境のセキュリティ対策に関する設計・実装を管理する方
- 組織のセキュリティ監視と運用を行い、インシデントの検知や対応を実施する方
ゴール
- AWS サービスを用いて、高度な脅威検知とインシデント対応を実施方法を学び、組織全体のセキュリティ管理の仕方を理解する
まとめ
- 組織全体のセキュリティを保護するには
- 全ての AWS アカウントをセキュリティ監視対象とする
- 脅威の検知、対応、調査を実施するには
- Amazon GuardDuty, AWS Security Hub, Amazon Detective など AWS で利用可能なセキュリティサービスを理解する
- AWS セキュリティサービスを活用するには
- AWS マルチアカウント環境において、AWS セキュリティサービスを有効化するだけでスケーラブルに展開する
サマリ
- AWS セキュリティサービスによる組織全体の保護
- AWS アカウントの理解
- AWS アカウントとは
- AWS クラウドサービスのリソースコンテナ
- 明示的なセキュリティ境界
- コストの追跡と請求のためのコンテナ
- 制限と閾値(サービスクォータや API 閾値など)を適用するメカニズム
- セキュリティアカウントによる検知・対応・調査
- 変化する環境において脅威を検知するには (Amazon GuardDuty)
- 脅威インテリジェンスと継続的監視により拡大していく AWS アカウントやリソースを効果的に保護
- データソース
- VPC フローログ
- DNS ログ
- CloudTrail イベント
- S3 データイベント
- Amazon GuardDuty が検出する既知の脅威
- 様々なソースからの脅威インテリジェンスを活用
- AWS 固有のインテリジェンス
- AWS パートナーの脅威インテリジェンス（CrowdStrike, Proofpoint）
- お客様が提供する脅威インテリジェンス
- 脅威インテリジェンスを用いて GuardDuty が識別するもの
- 既知のマルウェアに感染したホスト
- 匿名プロキシ
- マルウェアやハッカーツールをホストしているサイト
- 暗号通貨マイニングプールとウォレット
- Amazon GuardDuty が検出する未知の脅威
- 異常な振る舞いを検出するためのアルゴリズム
- ヒューリスティックのための信号パターンの検査
- 正常なプロファイリングと偏差の確認
- 機械学習による分類
- 検出結果の確認：Amazon EventBridge イベント
- GuardDuty が送信する一つのイベントには、脅威を検出してから 5 分間の情報が集約される
- EventBridge イベントは、グラフ化、保存、エクスポート、分析などに利用される
- 増大する脅威を監視し対応するには (AWS Security Hub)
- 特徴
- 調査結果を集約し時間を節約
- 自動チェックでセキュリティ体制を改善
- 厳選されたセキュリティベストプラクティス
- 標準化された検出結果フォーマットとのシームレスな統合
- マルチアカウントの統合
- ユースケースの概要
- 検出結果の優先順位付けとアクションの実行:
組織内の全ての AWS アカウントのセキュリティイベントを表示
- 統合と連携:
正規化された共通形式で、イベントを SIEM またはログ管理ツールに送信
- 可視性:
組織内の全ての AWS アカウントのコンプライアンス遵守状況を可視化
- AWS セキュリティサービスとの統合
- Amazon GuardDuty
- Amazon Inspector
- Amazon Macie
- AWS IAM Access Analyzer
- 自身のアカウント内のリソースに対して、外部からのアクセスを許可するポリシー記述を検出した時の検出結果
- AWS Firewall Manager
- AWS WAF ポリシーや Web ACL ルールのコンプライアンス非準拠時の検出結果
- AWS Shield Advanced によりリソース保護されていない、または攻撃を検知した時の検出結果
- AWS Systems Manager Patch Manager
- EC2 インスタンスがパッチベースラインに基づくコンプライアンスルールに非準拠の時の検出結果
- AWS Security Hub インサイト
- グループ化条件(Group By)によってフィルターされる検出結果
- セキュリティ評価の自動化
- 150 以上のセキュリティ項目の継続的評価を自動化
- 評価結果はダッシュボードに表示されすばやくアクセス可
- コンプライアンス遵守に役立つベストプラクティス情報の提供
- セキュリティ基準
- AWS 基礎セキュリティのベストプラクティス
- CIS AWS Foundations Benchmark
- AWS ソリューション
- AWS Security Hub の自動化された応答と修復 | 実装 | AWS ソリューション
- 対応すべき脅威を調査するには (Amazon Detective)
- セキュリティ問題の根本原因を迅速に分析、調査、特定
- Amazon Detective 利用フロー
- マルチアカウントのテレメトリデータ収集
- 継続的な集約とグラフモデルへの変換
- セキュリティアカウントによる集中管理
- Amazon GuardDuty, AWS Security Hub,Amazon Detective の権限移譲された管理アカウント (Delegated Administrator) にセキュリティアカウントを指定する
- AWS Organizations 配下のメンバーアカウントに対して、Amazon GuardDuty,AWS Security Hub を一括自動有効化可能
- Amazon Detective のメンバーアカウントは、セキュリティアカウントから招待することで関連付ける
ISMAP に基づくクラウドコンプライアンスの向上(AWS-48)
Link: ISMAP に基づくクラウドコンプライアンスの向上(AWS-48) - Summits JP Production
視聴対象者
政府情報システムのためのセキュリティ評価制度
（Information system Security Management and Assessment Program: 通称、ISMAP（イスマップ）)
- ISMAP の調達に関連する担当者（調達府省庁などにおいてサービス選定に関わる方）
- ISMAP を踏まえたサービスを展開しようとしている事業者（SaaS 事業者や SI 事業者のエンジニアや提案担当者）
- クラウドにおける調達やコンプライアンスを考えているリスク管理部門やコンプライアンス担当者（監査人等）
まとめ
- コンプライアンスとクラウドバイデフォルト
- ISMAP はクラウドバイデフォルト実現のための道具
- ISMAP がもたらすもの
- ISMAP によりクラウドサービス事業者のセキュリティに対する“信頼”を醸成
- AWS の ISMAP コンプライアンスがお客様に届ける価値
- AWS の ISMAP コンプライアンスだけではなく必要な情報や機能提供による、エコシステム拡充を支援
サマリ
- コンプライアンスとクラウドバイデフォルト
- Ref. 政府情報システムにおけるクラウドサービスの利用に係る基本方針
- Ref. 政府情報システムにおけるクラウドサービスの利用に係る基本方針（案）概要
- クラウドサービスの利用を第一候補
- 政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う（クラウドサービスにはパブリック及びプライベート（府省共通・府省内の提供する共通基盤等）を含める）
- 情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び経費等を基に検討を行う
- クラウドバイデフォルトは、オンプレミスを否定するものではない。
- “選択”のために重要となるセキュリティ評価
- クラウドバイデフォルトを実現する上での重要な要因は“セキュリティ”
- 事業者を正しく評価するためには、第三者認証やバックアップや災害対策などのリスク対応が可能な点が選定ポイントに
- パブリッククラウドのサービスによるプライベートクラウド環境の実現
- ISMAP がもたらすもの
- AWS の ISMAP コンプライアンスがお客様に届ける価値
- お客様に必要なのは、価値の最大化
- Ref. 政府情報システムにおけるクラウドサービスの利用に係る基本方針（案）概要
- クラウド調達にとって最も大切なことは利用者の選択肢の拡充による、より柔軟かつ迅速な調達の実現
- AWS はお客様のフィードバックにもとづきサービスを継続的にアップデート
- AWS のインフラストラクチャを活用することで、SaaS ベンダはより効率的に ISMAP に取り組むことが可能
- クラウド事業者による情報や機能の提供
- ISMAP の管理策には、利用者（AWS にとっては AWS 上にサービスを展開する SaaS 事業者等も該当）に対して、機能や情報を提供することを求める管理策が存在
- 利用者は要件やニーズに応じて、適切な実装や運用を実現することが期待される（責任共有モデルの実現）
- ISMAP のために特別なことではなく、様々なコンプライアンスプログラムと一貫性をもって実施
- 調達の未来：より迅速なクラウド調達の実現へ
- Ref. 速報！本日未明に終了した AWS 公共部門 サミットのハイライトを紹介します-前編【キーノート編】 | Amazon Web Services ブログ
- 米国で開催されている公共部門サミットでは、Federal Risk and Authorization Management Program (FedRAMP)への AWS の取り組みを紹介
- “AWS はパートナー各社との協力のもと、ユーザーのセキュリティ向上に注力
- AWS には、他のどのクラウドプロバイダーよりも多くの「FedRAMP 認定ソリューション」が引き続き存在し、セキュリティ基盤の構築に取り組む各機関のミッションに貢献
- 2020 年 5 月末時点で、110 ものサードパーティソリューションが AWS 上で FedRAMP 認証を取得
【基本の AWS サービス】AWS アカウントを守るためにおさえておきたいセキュリティ対策(AWS-52)
Link: 【基本の AWS サービス】AWS アカウントを守るためにおさえておきたいセキュリティ対策(AWS-52) - Summits JP Production
視聴対象者
- AWS の基本的な概念は知っている方
- AWS Well-Architected フレームワークをこれから学ぶ方
- AWS アカウント保護に不安がある方
ゴール
- このセッションを聞いたあと、自社のアカウントのセキュリティ対策をすぐに実施出来る
- セキュリティにおける、AWS Well-Architected レビューが出来るようになること
まとめ
- AWS Well-Architected フレームワークとは
- 10 年以上の経験、数多くのお客様と作りあげたクラウド設計・運用のベストプラクティス集
- AWS Well-Architected フレームワーク セキュリティの柱
- AWS アカウント保護に有効なベストプラクティスをご紹介
サマリ
- AWS Well-Architected フレームワークとは
- AWS Well-Architected フレームワーク セキュリティの柱について
- AWS Well-Architected フレームワークの活用
- AWS アカウントを守るために実施すべきセキュリティ対策
- 一元化された ID プロバイダーを利用し、一時的な認証情報を使用する
- AWS アカウントにおけるシングルサインオン
- ID フェデレーション with SAML
- 組織のアクセス許可ガードレールを定義する
- 予防的ガードレール
- 対象の操作を実施できないようにするガードレール
- Organizations Service Control Policy （SCP）で実装する
- AWS リソースや API へのアクセス制限を実現
- 発見的ガードレール
- 望ましくない操作を行なった場合、それを発見するガードレール
- 管理しつつ開発のスピードを上げるために効果的
- AWS Config Rules で実装する
- 組織のルールから逸脱していないかどうかを評価
- AWS アカウント保護に必要なセキュリティ対策 ‐ AWS アカウント全般編 ‐
- AWS アカウント保護における実施すべきベストプラクティス
- 強力なサインインメカニズムを使用する
- ルートユーザーの MFA を有効化し、アクセスキーを削除する
- 管理権限を持つ IAM ユーザーに MFA を設定する
- 一時的な認証情報を使用する
- シークレットを安全に保存して使用する
- 定期的に認証情報を監査およびローテーションする
- AWS Config ルールによるパスワードポリシーとアクセスキーローテーションのチェック
- AWS アカウント保護における実施すべきベストプラクティス
- サービスとアプリケーションのログ記録を設定する
- ログ、結果、メトリクスを一元的に分析する
- 検出結果に対してアクションをとる体制をつくる
AWS における安全な Web アプリケーションの作り方(AWS-55)
Link: AWS における安全な Web アプリケーションの作り方(AWS-55) - Summits JP Production
視聴対象者
ゴール
- Web アプリケーションの脆弱性に対して AWS やサードパーティのサービスを使って対応する⽅法を知る
- 開発のライフサイクルにおいて必要となるセキュリティの確認項⽬と対策項⽬を理解する
まとめ
- サービスにより責任の範囲は変化するが、常にアプリケーションのセキュリティ対策はお客様の責任範囲
- Web アプリケーションのセキュリティガイドラインを読み返して脆弱性と対策を理解しましょう
- アプリケーションの開発ライフサイクルにおいて必要となるセキュリティ対策が異なることを理解しましょう
- 各開発フェーズにおけるセキュリティ対策のポイントを確認しましょう
- 認証・認可とアクセス管理に注意
- アプリケーションフレームワークを正しく利⽤
- ログの取得とモニタリング
- コードレビューの実施
- セキュリティテストを実施
- 必要に応じて WAF による追加的な保護を実施
- 継続的なセキュリティテスト/脆弱性診断を実施
サマリ
- Web アプリケーションの脆弱性とセキュリティガイドライン
- Web アプリケーション脆弱性と攻撃の代表例
- SQL インジェクション
- XSS
- セッション管理の不備
- アクセス制御や認可制御の⽋落
- アプリケーションの保護はお客様の責任範囲
- 代表的なセキュリティガイドライン
- Web アプリケーションのセキュリティ対策
- 要件定義
- システム設計
- 認証⽅式の設計
- ログ設計
- セキュアプログラミング技法
- 開発・実装
- コーディング規約による制限
- ソースコードレビュー
- ソースコードセキュリティ検査
- テスト・検証
- 運⽤・保守
- 開発ライフサイクルとセキュリティ対策
- 認証・認可とアクセス管理に注意
- アプリケーションフレームワークを正しく利⽤
- ガイドラインで指摘されているセキュリティ脆弱性に対する対策は、最新版のフレームワークやライブラリを正しく利⽤することで実施できる
- 古いバージョンのフレームワークやライブラリは脆弱性を含むことがあるので必ず最新版を利⽤する
- セッション管理などは独⾃実装せずに、フレームワークやライブラリで提供されている機能をフル活⽤する
- サーバーレスのアプリケーションで Rest API を実装する際には Amazon API gateway を利⽤する
- ログの取得とモニタリング
- ログの取得は発⾒的統制(問題が起こったことを検知して対策すること)の上で重要
- ログの種類はアクセスログなどの AWS のサービスが出⼒するログとアプリケーション側で必要に応じて出⼒するログに分かれる
- AWS CloudTrail
- Elastic Load Balancing (ELB) アクセスログ
- Amazon CloudFront アクセスログ
- Amazon API Gateway
- VPC Flow Logs
- Amazon S3 バケット のアクセスログ
- DNS Query Logs
- フレームワークが出⼒するログは抑制せずにきちんと出⼒する
- コードレビューの実施
- エンジニア同⼠のコードレビューで防げる脆弱性も多い
- 必要に応じてコーディング規約を策定する
- フレームワークに沿った正しい実装ができているかをチェックする
- バグを減らすこともセキュリティ対策の⼀つ
- Linter によるチェックも活⽤する
- 必要に応じてソフトウェアを⽤いた静的アプリケーションセキュリティテスト (SAST) を活⽤する (次のセクションで詳しく説明)
- セキュリティテストを実施
- アプリケーションのリリース・運⽤前にソフトウェアを⽤いたセキュリティテストを活⽤する
- セキュリティテストには、ソースコードを実⾏せずに解析する静的アプリケーションセキュリティテスト (SAST) と実際にコードを実⾏して解析する動的アプリケーションセキュリティテスト (DAST) がある
- SAST と DAST はテスト対象とテストの⽬的が異なるため⼀⻑⼀短があり、可能な限り両⽅を実施することが望ましい
- 静的アプリケーションセキュリティテスト (SAST)
- Amazon CodeGuru Reviewer Security Detector
- GitHub Code Scanning によるセキュリティスキャン
- 動的アプリケーションセキュリティテスト (DAST)
- OWASP ZAP (Zed Attack Proxy)
- 侵⼊テストについて、テストが許可されたサービス
- Amazon EC2, NAT Gateway, Elastic Load Balancing
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateway
- AWS Lambda 及び Lambda Edge 関数
- Amazon Lightsail
- Amazon Elastic Beanstalk 環境
- 必要に応じて WAF による追加的な保護を実施
- 継続的なセキュリティテスト/脆弱性診断を実施
- アプリケーションは常に更新されるものであり⼀度のセキュリティテストだけでは不⼗分
- アプリケーションが変更されるたびに繰り返しコードレビューとセキュリティテストを実施する
- DevOps のパイプラインにセキュリティテストを組み込んだ DevSecOps も有効な⼿法の⼀つ
AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~
Link: AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~（パートナーセッション） - Summits JP Production
まとめ
- サーバレス（AWSLambda）でも責任共有モデルの考え方は重要
- サーバレスの特徴に合わせて防御戦略をとる
- 稼働は短命、OS の脆弱性管理不要、自由度も限定的
- サーバレスユーザが注意すべきはアプリケーションを狙う脅威
- サーバレスでも基本のセキュリティ対策は有効
- FaaS 上で多層防御（脆弱性の検査、ロギング、可視化、データへのアクセス制御
サマリ
- セキュリティ専門企業から見たサーバレスの特徴
- 「リスクが予想しにくい」ことが一番のリスク
- リスクの<発生頻度> と<影響度> が予測しにくいため『負けない設計』が重要
- サーバレスアーキテクチャは複雑系システムであるため、リスクを予測して対応するよりも、設計にセキュリティを組み込む方が有効
- サーバレス環境でユーザは何を守るべきか？
- 【特徴 ①】イベントソースの種類が格段に多い
- 攻撃対象が多い。WAF ではカバーしきれないレイヤーの保護が必要
- HTTP API
- Queue
- DB
- IoT Device
- 【特徴 ②】システム設計が複雑になる
- インシデントレスポンスのための可視化・検知が困難
- サーバに関わる業務を「意識する」必要がない
- 言語に依存しない機能の連携が容易
- スケーラビリティを前提とした設計が組める
- アプリケーションが関数に分割される
- 各関数がイベントをトリガーに指定タスクを実行
- 出力は各関数の依存関係で定義される
- 【特徴 ③】セキュリティテストだけでは不十分
- テストツールだけではなくアプリケーション防御ツールも必要
- 「攻撃ゼロ」ではなく「被害ゼロ」を目指す
- 「サーバレス脅威 TOP12」「OWASP TOP10」両方でインジェクションが 1 位
- 脆弱性を悪用する攻撃は公開事例の 1/4 を占める
- 高度なスキルを持つ攻撃者を想定する
- 標的型攻撃者を脅威モデルとして防御戦略を策定するべき
- 侵入を前提としたセキュリティ設計が鉄則
- 『内部を守る』ことが被害ゼロへの道
- 改めて『RASP（Runtime Application Self-Protection）』の価値を考える
- 企業内 NW は安全とみなす
- FW の内外が信頼の基準
- リクエストごとに検査
- セキュリティの埋め込み改めて『RASP（Runtime Application Self-Protection）』の価値を考える
- RASP とは、セキュリティをアプリケーションの機能の一部として組み込むことで、外部からアプリケーションに対する攻撃を検知・ブロックする保護手法
- TrendMicroCloudOne™ のご紹介
- AWS Lambda を狙った機密情報の搾取とその対策
- 脆弱性・設定不備等により Credential 流出
- AttachPolicy・PassRole で権限昇格
- 機密情報搾取・AWS アカウント乗っ取り等の AWS 環境の悪用
