Category: Security, Identity, & Compliance

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。（第一弾「クラウドにおける安全なデータの廃棄」はこちら） 今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か？を振り返るとともに、いくつかの理解のポイントをお伝えします。 セキュリティ責任共有モデルとは？ ”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。” 責任共有モデルを踏まえたセキュリティ効率性の改善 責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。 同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。 AWSは”クラウド内のセキュリティに対する責任”を助けないのか。 上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。 また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。 また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。 このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。 多くの”責任共有モデル”は二階層ではない。 上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。 重層的な責任共有モデルにどう向き合うか お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE）の設立などをベストプラクティスとしてお客様にお伝えしています。 責任共有モデルは”セキュリティだけ”のものではない。 このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、（特に公共部門の場合には）“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば：  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理（その頻度は週次であったり、日次で行うことも可能です）に主体性を持ち、次年度（場合によっては次期四半期）の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。 “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター（SI）によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者（あるいは、リセラーを含めた四者）によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。 […]

AWS Control Tower のリリース後、多くのお客様からいただいていたご要望がありました。既存のAWS Organizations に AWS Control Tower をデプロイすることと、組織が持つ他のアカウントにもガバナンスを拡張することです。 このたび、AWS Control Tower を既存の AWS Organization にデプロイできるようになったことをアナウンスいたします。一方で、AWS Control Tower をデプロイする前に作成した AWS アカウント（ここでは「未登録アカウント」と呼びます）は、デフォルトでは AWS Control Tower ガバナンスの範囲外になります。そのため、これらの未登録アカウントは明示的に AWS Control Tower へ登録する必要があります。 既存アカウントを AWS Control Tower へ登録することで、アカウントベースライン（基本設定）と追加のガードレールが配備され、継続的なガバナンス（Continuous Governance）が有効になります。なお、アカウントを登録する前には、適切なデューデリジェンス（事前評価）を行う必要があります。以下に記載されている「考慮すべき事項」セクションの追加情報を参照してください。 このブログでは、AWS Organizations 内の 未登録 AWS アカウントと 未登録 OU(Organization Units = 組織単位)内のアカウントを、プログラムによって AWS Control Tower へ登録する方法を解説します。

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、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アップデート 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 ルールはありますか？ A. パートナーManagedルールに、Amazon API Gateway […]

 本日、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 […]