Category: Security, Identity, & Compliance

先日 (2020/07/22) 開催しました AWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用 AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS Single Sign-On (SSO) のアクセス権限セットですが、IAM ロールやグループ、ポリシーとは独立したものという認識で正しいですか？AWS Single Sign-On (SSO) の管理者がメンテする必要があるのかと思っています。 A. はい。アクセス権限セットは AWS Organizations マスターアカウントの IAM ロールやグループ、ポリシーとは独立したものになります。AWS Single Sign-On (SSO) の管理画面を通じて管理者が設定したアクセス権限セットに基づいて、メンバーアカウントのロールやポリシーが構成されます。 Q. AWS Organizations のマスターアカウントではなくメンバーアカウントで AWS Single Sign-On (SSO) の設定を行うことは可能でしょうか？ A. メンバーアカウントのユーザーが AWS […]

AWSのお客様とパートナー様は、一般データ保護規則（GDPR）を含むEUのデータ保護法を遵守した上で、AWSを利用して欧州から米国やその他の国へコンテンツを転送することができることをお知らせしたいと思います。

先日 (2020/07/15) 開催しました AWS Black Belt Online Seminar「Amazon Detective」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200715 AWS Black Belt Online Seminar Amazon Detective AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Amazon GuardDuty の有効化後、48時間経過すれば必ず有効化できますか？ A. はい、有効化できます。Amazon GuardDuty 有効化後の48時間以内に Amazon Detective を有効化しようとするとエラーメッセージが表示され有効化ができませんが、48時間経過すると、このメッセージも表示されず有効化することができます。 Q. 複数の AWS アカウントを運用している場合、どのような構成がベストプラクティスになりますでしょうか？（各 AWS アカウントで有効化する／ログを1つの AWS アカウントに集約して有効化する、など） A. すべてのアカウントで有効化をして、１つのアカウントで検出結果の管理を行うのを推奨しております。最初に、マスターアカウントを一つ選択してください。他のAWSアカウントはメンバーアカウントになります。次に、Amazon GuardDuty または AWS Security Hub のサービスを有効化して、このマスターアカウントがメンバーアカウントの検出結果を管理できるようにしてください。最後に、Amazon Detective でも同じマスターアカウントとメンバーアカウントの関係を維持してください。これによって組織全体で脅威を一元管理ができ、Amazon Detective で迅速に調査ができるようになります。 Q. Detective は […]

先日 (2020/06/30) 開催しました AWS Black Belt Online Seminar「Amazon Cognito」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200630 AWS Black Belt Online Seminar Amazon Cognito AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. ユーザープール、Cognito ID プールはどこに保存されるのでしょうか？例えば貴社でご用意する Cognito 用インスタンスのローカル等に保存されるイメージでしょうか？ A. お客様が指定された AWS リージョン内の Amazon Cognito 環境内に保存されます。 Q. ユーザープールに登録した情報（usename、password、email, tel）のバックアップとリストアは、どのように行えばよいですか？ A. Cognito ユーザプールはバックアップやリストアの機能は提供していませんが、ユーザプールに登録された情報は、安全に保存されています。そのため、単一リージョン内での耐久性では不十分な場合や操作ミスからの復旧が、バックアップやリストアの目的になるかと思われます。 前者への対応としては、定期的に全ユーザの属性を読み取って S3 や DB 等に保存しておく、あるいはユーザの新規・変更時に都度 DB にも記録する、ログイン時に発行される ID トークンの内容を都度 DB に反映しておくといった事をしておき、それをさらに別リージョンにもコピーするという方法が考えられます。ただし、パスワードは取り出すことはできません。万が一リストアする際は、バックアップデータからユーザ情報を Cognito ユーザプールに再登録し、パスワードについてはユーザの方に再設定して頂くことになります。なお、構成によってはユーザの入力したパスワードを DB 等に記録しておくことも不可能ではありませんが、セキュリティ上おすすめしません。 […]

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

本Blogでは日本時間の本日未明に終了した「AWS Public Sector Summit Online」 における、ブレイクアウトセッションのハイライトをご紹介いたします（記載は2020年7月1日時点）。 【キーノート編】も本日併せて公開されておりますので、ご参照ください（こちら。World Wide Public Sector部門のバイス・プレジデントであるテレサ・カールソンが登壇した基調講演のハイライトです）。　YouTubeでの動画公開が可能となり次第、各セッションへのリンクも貼られる予定です。 おすすめのブレイクアウト・セッション 以下、日本のお客様向けに、今回のサミットで開催された２５のブレイクアウト・セッションの中から幾つかをご紹介させていただきます（開催終了後も、こちらに登録いただくことで全セッションを聴講いただくことが可能です。 公共機関のＤＸ、マネジメント＆イノベーション系のセッション： “Critical components for transformation within an international government context” Céline Degrauwe（Digital Transformation Adviser for Government, AWS）は、次のように述べます。　いずれの国の政府機関にとっても、①「リーダーによる強力なコミットメント」、②“イノベーションを選好する文化の確立” – 例えば「デザイン・シンキング」を起点とし、市民のニーズからミッションとツールとしてのテクノロジーを逆算して設定、③データ・クラシフィケーションを自組織内で実施し、クラウドに相応しい分類方針をセットすることが必要──である旨、３つの考え方を紹介しています。例えば、“Gov.BR”の事例では、Brazilの政府機関では４００以上の新しいデジタルサービスを投入しています。AWSも、「Executive Education」を」 を標準3日間のコースとして提供し、政府部門のDXを支援しています。民間部門と公共部門の大部分の重要なデータは合致し、現代では多大な協働が期待されています。“Procurement is the gateway to innovation“とも述べ、各国でのクラウドの買い方に関する調達改革の必要性もこのセッションでは強調されました。 “Understanding optimizing costs with the AWS Cloud” ── David Lurie（Business Development Capture Manager Canada, Worldwide Public sector, […]

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。１つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる（3 つの防御ラインにまたがった）リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった１つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています（したがって、同じ評価が必要なコントロールを決定する適切な方法とされます）。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません（たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません）。最も重要な点は、既存の統制基盤を考慮していないことです（したがって、追加のコントロールの必要性を過大評価してしまう可能性があります）。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

AWS Shield は、アプリケーションの脆弱性、不正なボット、分散サービス妨害（DDoS）攻撃から AWS で実行されているアプリケーションを保護する、マネージド型脅威保護サービスです。AWS Shield の脅威ランドスケープレポート（TLR）は、AWS Shield によって検出された脅威の概要が説明されています。このレポートは、AWS のお客様に代わって保護を構築するために、脅威状況を継続的に監視、評価している AWS 脅威リサーチチーム（TRT）によって作成されたものです。これには、 AWS WAF の AWS マネージドルール や AWS Shield Advanced など、サービスのルールと緩和策が含まれています。この情報を使用して、外部の脅威に関する知識を広げ、AWS で実行されるアプリケーションのセキュリティを向上させることができます。 2020 年第 1 四半期を対象とする最新のレポートから、調査結果の一部をご紹介します。

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。

アマゾン ウェブ サービス （AWS）がはじめて PCI 3-D Secure (3DS) 認定を取得したことをお知らせいたします。AWS は 3DS 機能を直接提供しませんが、AWS の PCI 3DS準拠証明書により、お客様が AWS で実行されているサービスに対して PCI 3DS 準拠を実現できます。