Category: Security, Identity, & Compliance

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。

本投稿は ワールドワイドで金融業界を担当している プリンシパルソリューションアーキテクト の Ilya Epshteyn による寄稿を翻訳したものです。 グローバル展開されている金融事業グループの中でプリンシパルソリューションアーキテクトとして、私が最もよく聞かれる質問の1つは、特定の AWS サービスが 金融サービスで利用可能かどうかです。金融サービスのような規制された業界では、クラウドへの移行は単純なリフト＆シフト作業ではありません。代わりに、金融機関は、 一般的にホワイトリストと呼ばれる秩序だったサービスごとの評価プロセスを使用して、クラウドサービスが規制上の義務にどのように対応できるかを実証しています。このプロセスが明確に定義されていない場合、クラウドにデータを移行する作業が遅れる可能性があります。 この記事では、最も機密性の高いデータに対するクラウドサービスのホワイトリスト化を簡素化するため、金融機関が焦点を当てるべき 5つの重要な考慮事項 で構成されるフレームワークについてご説明します。また、⾦融サービス組織がこの作業をする上で役⽴つ重要な AWS 機能についても概説します。 5 つの重要な考慮事項は、以下の通りです： コンプライアンスの達成 データ保護 コンピューティング環境の隔離 API による監査の自動化 運用上のアクセスとセキュリティ 私がこれまで関わってきたビジネスリーダーやテクノロジーリーダーの多くにとって、俊敏性と素早い変革がクラウド化の最大の推進要因です。金融サービス機関はクラウドに移行することで、パーソナライズされたデジタルエクスペリエンスの開発、データサイロの打破、新商品の開発、既存商品の利益率の向上、グローバルなリスクとコンプライアンス要件への積極的な対応を行いやすくしています。幅広い AWS サービスを使用する AWS のお客様は、クラウド導入の段階を進むにつれて俊敏性を高めることができるようになります。幅広いサービスを使用することで、組織は差別化につながらない面倒な部分を AWS に任せて、コアビジネスと顧客に集中することができます。 私の目標は、金融サービス機関が（本番環境とミッションクリティカルなワークロードの両方で）自社の極めて機密性の高いデータをクラウドに移行することに対し、ガイドを提供することです。以下の考慮事項は、金融サービス組織がクラウドサービスへの準備状況を判断し、クラウドで成功を収めるのに役立つでしょう。 1. コンプライアンスの達成 ホワイトリストのプロセスを使用する金融機関にとっての最初のステップは、クラウドサービスプロバイダー (CSP) のサービスの基盤となるコンポーネントが、基準となるコンプライアンスのベースラインを満たせるようにすることです。これについて確信を持つための重要な前提条件は、 AWS 責任共有モデルを理解することです。責任共有とは、AWS 上でアプリケーションが安全に機能するためには、CSP としてのAWSおよびお客様との両者でのアクションが必要であることを意味します。AWS のお客様は、クラウド 内 のセキュリティに責任があります。お客様は、コンテンツ、アプリケーション、システム、ネットワークのセキュリティを制御および管理します。 AWS は、 クラウドの セキュリティを管理し、サービスと機能の適切な運用の提供および維持し、AWS のインフラストラクチャとサービスの保護、運用上の優秀性の維持、関連する法的および規制要件を満たします。 責任共有モデルのAWS 側への信頼を確信するために、お客様は、独立した第三者監査人が作成したAWS System and Organization Controls […]

クラウド・セキュリティを向上させたいと考えているなら、AWS のチーフ・インフォメーション・セキュリティ・オフィサー (CISO) であるステファン・シュミットが AWS re:Invent 2019で発表したクラウド・セキュリティのための上位 10 個の項目 を参照してみてはいかがでしょうか？ 下記が項目のサマリーです。皆様の理解のために、順番に説明していきます。 1) アカウント情報を正しく保つ AWS が AWS アカウントについて連絡が必要な場合、AWS マネジメントコンソールで設定された連絡先の情報を利用します。これは、アカウントを作成する時に指定した E メールアドレス、代替の連絡先の中で指定されている E メールアドレスになります。全ての E メールアドレスは個人に依存しないようにエイリアスのアドレスにするべきです。また、定期的に指定している E メールアドレスが有効で、E メールが届いた時に返信可能かどうかを確認するプロセスが必要です。特に、 abuse@amazon.com から受信する可能性のあるセキュリティに関する通知に返信出来るかどうかが重要です。あなた自身が不在の時に、他の誰かがメール受信を出来るように代替の連絡先指定のマニュアルページで確認してみてください。 2) 多要素認証 (MFA) を利用する MFA は不正なアクセスからアカウントを保護するためのベストな方法の１つです。MFA をルートユーザおよび AWS Identity and Access Management (IAM) ユーザに対して設定してください。AWS へのアクセス制御に AWS Single Sign-On (SSO) を使っていたり、企業内の ID ストアとフェデレーションを指定している場合には、MFA を Identity Provider (IdP) […]

私はほぼ 5 年前、機密の API 使用時に AWS CloudTrail データを自動的に分析してアラートを生成するソリューションについてブログを書きました。これは、セキュリティ分析と自動化のためのシンプルで基本的なソリューションでした。けれども、要求水準の高い AWS のお客様は複数の AWS アカウントを持ち、複数のソースからデータを収集しています。そのため、正規表現に基づく簡単な検索では、疑わしいセキュリティ関連イベントの詳細な分析を行うには不十分です。差し当たり、セキュリティの問題 (資格情報の侵害やリソースへの不正アクセスなど) が検出されると、セキュリティアナリストは複数のデータログをクロス分析して、問題の根本原因と環境への影響を理解しようとします。詳細な分析では、複数のサイロ化されたシステムによって生成されたデータ間のドットをつなげるために、スクリプトと ETL が必要になることがよくあります。「これは正常か?」といった基本的な質問に答えるには、熟練したデータエンジニアが必要です。アナリストは、セキュリティ情報およびイベント管理 (SIEM) ツール、サードパーティライブラリ、およびデータ視覚化ツールを使用して、データを検証、比較、および関連付けて、結論に達します。問題をさらに複雑にしているのは、新しい AWS アカウントと新しいアプリケーションが常に導入されるため、アナリストは通常の動作のベースラインを常に再構築し、新しいセキュリティ問題を評価するたびにアクティビティの新しいパターンを理解する必要がある点です。 Amazon Detective は、セキュリティ上の問題の原因と影響を特定するために、大量の AWS ログデータの処理に伴う多大な労力を自動化できるようにしたフルマネージドサービスです。有効にすると、 Detective は自動的に AWS Guard Duty、AWS CloudTrail、および Amazon Virtual Private Cloud フローログからのデータの抽出と整理を開始し、AWS 環境全体で観察されたリソースの動作と相互作用を要約したグラフモデルに変換します。 re:invent 2019 で、 Amazon Detective のプレビューを発表しました。本日、すべての AWS のお客様にご利用いただけるようになったことをお知らせします。 Amazon Detective は、機械学習モデルを使用してアカウントの動作のグラフィック表現を生成し、「これはこのロールにとって異常な API 呼び出しか?」や「このインスタンスからのトラフィックの急増は予想されているか?」といった質問に答えるのに役立ちます。独自のクエリを設定または調整するために、コードを記述する必要はありません。 Amazon Detective を使用開始するには、 AWS マネジメントコンソールを開き、検索バーに「detective」と入力し、表示された結果から […]

先日 (2020/03/24) 開催しました AWS Black Belt Online Seminar「AWS WAFアップデート」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200324 AWS Black Belt Online Seminar AWS WAFアップデート from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS Managed rules for AWS WAF は AWS WAF Classic でも利用できますか？ A. AWS Managed rules for AWS WAF は、AWS WAF Classic では利用できません。 Q. Amazon API Gateway に最適化された Managed […]

 本日、AWS Certificate Manager (ACM) またはお客様が提供する証明書を使用して、サービス間のトラフィック暗号化を可能にする AWS App Mesh 機能を一般公開しました。昨年、AWS App Mesh ロードマップの問題 #38 および #39 を通じてお客様からのフィードバックを求め、お客様が試用できるよう、AWS App Mesh Preview Channel で機能を利用できるようにしました。 メッシュアーキテクチャを構築するお客様は、サービス間のトラフィックの暗号化を要求するセキュリティおよびコンプライアンスのベースラインを有している場合があります。さらに、TLS の使用を強制し、アップストリームサービスからの証明書を検証することは、ゼロトラストネットワークの重要な側面です。この機能を使用すると、接続が安全であり、トラフィックが信頼できるサービスに送信されることを保証できます。 App Mesh では、仮想ノード間、そしてサービスメッシュの Envoy 間でトラフィック暗号化が行われます。これは、アプリケーションコードが TLS 暗号化セッションのネゴシエーションに責任を負わず、ローカルプロキシがアプリケーションに代わって TLS の交渉および終了を行うことを許可することを意味します。 図 1: 使用中の AWS インフラストラクチャのコンテキストでのサービス間のトラフィック暗号化フロー 仮想ノードの証明書ソース: ACM およびお客様が提供する証明書 GitHub ロードマップの問題 #38 では、ローカルファイルシステムから証明書を取得する機能を追加し、問題 #39 では、ACM から仮想ノードの証明書を取得する機能を追加しました。仮想ノードの証明書を設定する場合、お客様は、これらの利用可能なソースのいずれかを選択できます。 図 2: ACM 管理の証明書を使用した AWS App Mesh […]

Gyuho Lee、Rashmi Dwaraka、Michael Hausenblas Amazon EKS で AWS の暗号化プロバイダーをネイティブにサポートする計画を発表した際、皆さまから頂いたご意見の大半は「すぐ入手したいのですが」というものでした。 高度な防御のための重要なセキュリティ機能である、暗号化プロバイダー向けの EKS サポートを開始しました。これで、独自のマスターキーを使用し、EKS で Kubernetes シークレットのエンベロープ暗号化を使用できるようになりました。この投稿では、その背景と開始方法について解説します。 背景 Kubernetes のシークレットで、パスワードや API キーなどの機密情報を Kubernetes 固有の方法で管理できます。たとえば、kubectl create secret を使用してシークレットリソースを作成すると、Kubernetes API サーバーは base64 エンコード形式で etcd に保存します。EKS では、AWS が管理する暗号化キーを使用してディスクレベルで暗号化された etcd ボリュームを処理します。 エンベロープ暗号化とは、キーを別のキーで暗号化することです。なぜこれが必要なのでしょうか? これは、機密データを保存するアプリケーションに対するセキュリティのベストプラクティスで、高度な防御のためのセキュリティ戦略の一部でもあるからです。つまり、AWS KMS にマスターキーを (長期) 保存し、Kubernetes API サーバーでのデータキー生成に使用します。このキーは Kubernetes シークレットに保存した機密データの暗号化/復号化に使用します。 これまで、エンベロープ暗号化のために EKS で独自のマスターキーを使用するネイティブな方法はありませんでした。今回のリリースで、GoDaddy の外部シークレットや HashiCorp Vault などの外部ソリューションを操作して、Kubernetes シークレットを独自のキーで暗号化する必要がなくなりました。AWS KMS を使用すれば、EKS […]

セットアップとメンテナンスを簡素化し、AWS Managed Microsoft AD ディレクトリのコストを削減しながら、Amazon Relational Database Service (RDS) for SQL Server DB インスタンスのセキュリティを強化するにはどうすればよいですか? AWS は、複数の AWS アカウントと Amazon VPC にデプロイされた Amazon RDS for SQL Server DB インスタンスが、AWS リージョン内の Microsoft Active Directory (AWS Managed Microsoft AD) の単一の AWS Directory Service に参加できるようになったことを発表しました。これにより、ディレクトリをセットアップしてそのセキュリティ設定を一度行えば、すべての DB インスタンスの認証に使用できるため、ディレクトリ対応データベースのワークロードを管理しやすくなります。この記事では、アカウント間および VPC 間ドメインに参加するために Amazon RDS DB インスタンスを準備する方法について学びます。 注: この記事は Amazon RDS for SQL […]

このブログ記事では、オープンソースのセキュリティツールである Prowler を AWS Security Hub と統合する方法を紹介します。Prowler は Amazon Redshift、Amazon ElasticCache、Amazon API Gateway および Amazon CloudFront などのサービスに関する多数のセキュリティ構成チェックを提供します。Prowler と Security Hub を統合すると、既存の Security Hub 連携、またはコンプライアンス標準で現在ではカバーされていないリソースに関する情報が提供されます。Prowler チェックを使用することで、Security Hub で既に提供されている既存の CIS AWS Foundations コンプライアンスや、パートナーソリューションから取り込むコンプライアンス関連の検出結果を補うことができます。 この記事では、Docker を使用して Prowler をコンテナ化し、サーバーレスコンテナサービス AWS Fargate でホストする方法について説明します。Prowler を Fargate で実行すると、インフラストラクチャのプロビジョニング、構成、拡張が不要になり、必要なときにのみ実行されます。コンテナはアプリケーションのコード、設定、および依存関係をどこでも実行できる１つのオブジェクトにパッケージ化する標準的な方法を提供します。サーバーレスアプリケーションは、サーバーのプロビジョニング、スケーリング、および管理を必要とせずに、ユーザーが定義したイベントに応じて自動的に実行およびスケーリングされます。

2019年6月の re:Inforce 2019 で、AWS は AWS Security Hub の正式リリースを発表しました。AWS Security Hubは、お客様がコンプライアンスチェックとセキュリティの評価結果を AWS アカウント間で共有し、一元的に表示、管理できるセキュリティサービスです。AWS Security Hub は AWS Guard Duty、Amazon Inspector、Amazon Macie、および 30 以上の AWS パートナーセキュリティソリューションからセキュリティ検出結果をインポートできます。 デフォルトでは、Security Hubが有効になると、CIS AWS Foundations がお客様のアカウントにデプロイされます。 CIS AWS Foundations は、AWS アカウントを強化するためのセキュリティ設定のベストプラクティスのセットです。Security Hub が CIS AWS Foundations に含まれているルールでコンプライアンスチェックを実行するためには、AWS Security Hub を有効にしたアカウントと同じアカウントで AWS Config を有効にする必要があります。 AWS Security Hub を有効にする前に、独自の AWS Config ルールを作成したことがある場合は、それらを AWS Security […]