10
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

AWS SUMMIT ONLINE セキュリティ関連セッションまとめ

Posted at

概要

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 アイデンティティサービス

Link:【基本の AWS サービス】入門! AWS アイデンティティサービス(AWS-37) - Summits JP Production

視聴対象者

  • AWS の基本的な概念は知っている方
  • 1つの AWS アカウントで利用しているが、だんだん管理が難しくなってきたと感じている方
  • 組織での AWS の利用を検討している方

ゴール

  • AWS のアイデンティティサービスで出来ることを知る
    • 効率的なアクセス権限の管理方法
    • マルチアカウントのメリットと、その実現方法
    • 最小権限の原則にそったアクセス権限のアプローチ

まとめ

  1. AWS のアイデンティティ
    • 3つの要素をベースにした IAM 管理の仕組み
  2. マルチアカウント環境でのアイデンティティ管理
    • マルチアカウントのメリット
    • AWS Organizations、AWS SSO などで簡単に構築
  3. 最小権限を実現するためのテクニック
    • IAM アクセスアドバイザーによる確認

AWS アイデンティティサービスで効率的で安全なアクセス権限の管理を!

サマリ
  • AWS のアイデンティティ
  • マルチアカウント環境でのアイデンティティ管理
    • 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 の禁止など
    • 最小権限を実現するためのテクニック
      1. IAM のアクセスアドバイザーで各 AWS サービスの最終利用時間をチェック
      2. 必要ないことを確認後、アクセス権限を削除する

AWS におけるネットワーク&アプリケーション保護のすすめ(AWS-38)

Link: AWS におけるネットワーク&アプリケーション保護のすすめ(AWS-38) - Summits JP Production

視聴対象者

スタートアップからエンタープライズまで、AWS のセキュリティアーキテクチャに関わる⽅

まとめ

  • AWS の境界防御サービスの概要
    • AWS Network Firewall
    • AWS WAF
    • AWS Shield Advanced
  • アプリケーションの要件に応じた設計の勘所
    • ⼀般的な Web アプリケーション
    • 遅延にシビアなアプリケーション
    • サーバーレスアプリケーション
    • オンプレミスアプリケーション
  • 統制と運⽤をスケールさせる⽅法
    • AWS Firewall Manager
サマリ
  • AWS の境界防御サービスの概要
    • alt
    • 境界防御サービス
      • 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 Firewall Manager(ファイアウォールルールの一元管理)| AWS
      • 組織(Organizations)全体で AWSNetwork Firewall、WAF、Shield、および VPC セキュリティグループを使⽤してベースラインセキュリティを⼀元的に有効
      • 新しいアプリケーションが作成された場合でも、⼀貫して保護を強制
      • AWS アカウント全体で境界防御の状況を⼀元的に可視化

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)
    • 特徴
      • 調査結果を集約し時間を節約
      • 自動チェックでセキュリティ体制を改善
      • 厳選されたセキュリティベストプラクティス
      • 標準化された検出結果フォーマットとのシームレスな統合
      • マルチアカウントの統合
    • ユースケースの概要
      1. 検出結果の優先順位付けとアクションの実行:
        組織内の全ての AWS アカウントのセキュリティイベントを表示
      2. 統合と連携:
        正規化された共通形式で、イベントを SIEM またはログ管理ツールに送信
      3. 可視性:
        組織内の全ての 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 ソリューション
  • 対応すべき脅威を調査するには (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 コンプライアンスがお客様に届ける価値
    • お客様に必要なのは、価値の最大化
    • クラウド事業者による情報や機能の提供
      • ISMAP の管理策には、利用者(AWS にとっては AWS 上にサービスを展開する SaaS 事業者等も該当)に対して、機能や情報を提供することを求める管理策が存在
      • 利用者は要件やニーズに応じて、適切な実装や運用を実現することが期待される(責任共有モデルの実現)
      • ISMAP のために特別なことではなく、様々なコンプライアンスプログラムと一貫性をもって実施
    • 調達の未来:より迅速なクラウド調達の実現へ

【基本の 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 フレームワーク セキュリティの柱
    • 10 個の質問とベストプラクティスを利用可能
  • AWS アカウント保護に有効なベストプラクティスをご紹介
    • すぐに実践できるセキュリティ対策を検討する
サマリ

AWS における安全な Web アプリケーションの作り方(AWS-55)

Link: AWS における安全な Web アプリケーションの作り方(AWS-55) - Summits JP Production

視聴対象者

  • Web アプリケーションエンジニア
  • 開発の責任者

ゴール

  • Web アプリケーションの脆弱性に対して AWS やサードパーティのサービスを使って対応する⽅法を知る
  • 開発のライフサイクルにおいて必要となるセキュリティの確認項⽬と対策項⽬を理解する

まとめ

  • サービスにより責任の範囲は変化するが、常にアプリケーションのセキュリティ対策はお客様の責任範囲
  • Web アプリケーションのセキュリティガイドラインを読み返して脆弱性と対策を理解しましょう
  • アプリケーションの開発ライフサイクルにおいて必要となるセキュリティ対策が異なることを理解しましょう
  • 各開発フェーズにおけるセキュリティ対策のポイントを確認しましょう
    1. 認証・認可とアクセス管理に注意
    2. アプリケーションフレームワークを正しく利⽤
    3. ログの取得とモニタリング
    4. コードレビューの実施
    5. セキュリティテストを実施
    6. 必要に応じて WAF による追加的な保護を実施
    7. 継続的なセキュリティテスト/脆弱性診断を実施
サマリ
  1. Web アプリケーションの脆弱性とセキュリティガイドライン
  2. Web アプリケーションのセキュリティ対策
    • 要件定義
      • セキュリティ要件定義
      • リスク分析
    • システム設計
      • 認証⽅式の設計
      • ログ設計
      • セキュアプログラミング技法
    • 開発・実装
      • コーディング規約による制限
      • ソースコードレビュー
      • ソースコードセキュリティ検査
    • テスト・検証
      • セキュリティテスト
      • 脆弱性診断
    • 運⽤・保守
      • 脅威や脆弱性情報の収集
      • 定期的な脆弱性診断
  3. 開発ライフサイクルとセキュリティ対策
    1. 認証・認可とアクセス管理に注意
    2. アプリケーションフレームワークを正しく利⽤
      • ガイドラインで指摘されているセキュリティ脆弱性に対する対策は、最新版のフレームワークやライブラリを正しく利⽤することで実施できる
      • 古いバージョンのフレームワークやライブラリは脆弱性を含むことがあるので必ず最新版を利⽤する
      • セッション管理などは独⾃実装せずに、フレームワークやライブラリで提供されている機能をフル活⽤する
      • サーバーレスのアプリケーションで Rest API を実装する際には Amazon API gateway を利⽤する
    3. ログの取得とモニタリング
      • ログの取得は発⾒的統制(問題が起こったことを検知して対策すること)の上で重要
      • ログの種類はアクセスログなどの AWS のサービスが出⼒するログとアプリケーション側で必要に応じて出⼒するログに分かれる
        • AWS CloudTrail
        • Elastic Load Balancing (ELB) アクセスログ
        • Amazon CloudFront アクセスログ
        • Amazon API Gateway
        • VPC Flow Logs
        • Amazon S3 バケット のアクセスログ
        • DNS Query Logs
      • フレームワークが出⼒するログは抑制せずにきちんと出⼒する
    4. コードレビューの実施
      • エンジニア同⼠のコードレビューで防げる脆弱性も多い
      • 必要に応じてコーディング規約を策定する
      • フレームワークに沿った正しい実装ができているかをチェックする
      • バグを減らすこともセキュリティ対策の⼀つ
      • Linter によるチェックも活⽤する
      • 必要に応じてソフトウェアを⽤いた静的アプリケーションセキュリティテスト (SAST) を活⽤する (次のセクションで詳しく説明)
    5. セキュリティテストを実施
      • アプリケーションのリリース・運⽤前にソフトウェアを⽤いたセキュリティテストを活⽤する
      • セキュリティテストには、ソースコードを実⾏せずに解析する静的アプリケーションセキュリティテスト (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 環境
    6. 必要に応じて WAF による追加的な保護を実施
    7. 継続的なセキュリティテスト/脆弱性診断を実施
      • アプリケーションは常に更新されるものであり⼀度のセキュリティテストだけでは不⼗分
      • アプリケーションが変更されるたびに繰り返しコードレビューとセキュリティテストを実施する
      • DevOps のパイプラインにセキュリティテストを組み込んだ DevSecOps も有効な⼿法の⼀つ

AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~

Link: AWS Lambda を攻撃してみた ~サーバレスのセキュリティの考え方~(パートナーセッション) - Summits JP Production

まとめ

  • サーバレス(AWSLambda)でも責任共有モデルの考え方は重要
  • サーバレスの特徴に合わせて防御戦略をとる
    • 稼働は短命、OS の脆弱性管理不要、自由度も限定的
  • サーバレスユーザが注意すべきはアプリケーションを狙う脅威
    • 脆弱性からの侵害
    • 過大な権限付与からの権限昇格
  • サーバレスでも基本のセキュリティ対策は有効
    • FaaS 上で多層防御(脆弱性の検査、ロギング、可視化、データへのアクセス制御
サマリ
  1. セキュリティ専門企業から見たサーバレスの特徴
    • 「リスクが予想しにくい」ことが一番のリスク
      • リスクの<発生頻度> と<影響度> が予測しにくいため『負けない設計』が重要
      • サーバレスアーキテクチャは複雑系システムであるため、リスクを予測して対応するよりも、設計にセキュリティを組み込む方が有効
    • サーバレス環境でユーザは何を守るべきか?
      • アプリケーション
      • データ
      • 認証/認可
      • ログ
    • 【特徴 ①】イベントソースの種類が格段に多い
      • 攻撃対象が多い。WAF ではカバーしきれないレイヤーの保護が必要
        • HTTP API
        • Queue
        • DB
        • IoT Device
    • 【特徴 ②】システム設計が複雑になる
      • インシデントレスポンスのための可視化・検知が困難
        • サーバに関わる業務を「意識する」必要がない
        • 言語に依存しない機能の連携が容易
        • スケーラビリティを前提とした設計が組める
        • アプリケーションが関数に分割される
        • 各関数がイベントをトリガーに指定タスクを実行
        • 出力は各関数の依存関係で定義される
    • 【特徴 ③】セキュリティテストだけでは不十分
      • テストツールだけではなくアプリケーション防御ツールも必要
  2. 「攻撃ゼロ」ではなく「被害ゼロ」を目指す
    • 「サーバレス脅威 TOP12」「OWASP TOP10」両方でインジェクションが 1 位
    • 脆弱性を悪用する攻撃は公開事例の 1/4 を占める
    • 高度なスキルを持つ攻撃者を想定する
      • 標的型攻撃者を脅威モデルとして防御戦略を策定するべき
    • 侵入を前提としたセキュリティ設計が鉄則
      • サーバレス環境でも『各レイヤーでの防御』が効果大
    • 『内部を守る』ことが被害ゼロへの道
      • 改めて『RASP(Runtime Application Self-Protection)』の価値を考える
        • 企業内 NW は安全とみなす
        • FW の内外が信頼の基準
        • リクエストごとに検査
        • セキュリティの埋め込み改めて『RASP(Runtime Application Self-Protection)』の価値を考える
        • RASP とは、セキュリティをアプリケーションの機能の一部として組み込むことで、外部からアプリケーションに対する攻撃を検知・ブロックする保護手法
  3. TrendMicroCloudOne™ のご紹介
  4. AWS Lambda を狙った機密情報の搾取とその対策
    1. 脆弱性・設定不備等により Credential 流出
    2. AttachPolicy・PassRole で権限昇格
    3. 機密情報搾取・AWS アカウント乗っ取り等の AWS 環境の悪用
10
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?