Category: Security, Identity, & Compliance

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。 AWS Organizations がプレビューから一般公開へ このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、AWS Management Console、AWS Command Line Interface (CLI)、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。 組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS […]

当社のお客様は、これまでディレクトリ (一般的には Active Directory ライトウェイトディレクトリサービスや LDAP ベース) を使って階層別に整理されたデータを管理してきました。しばしば階層として表されるものには、デバイスレジストリ、コースカタログ、ネットワーク設定、ユーザーディレクトリがあり、同じコレクション内のオブジェクト間で複数のタイプの関係を持つ場合もあります。たとえば、ユーザーディレクトリは物理的な場所 (国、都道府県、市町村、建物、フロアー、オフィス) に基づいて 1 つの階層を持ち、プロジェクトや請求コードに基づいて 2 つ目の階層を持ち、管理チェーンに基づいて 3 つ目の階層を持つ場合があります。ただし、従来のディレクトリ技術では、単一のディレクトリ内で複数の関係の使用がサポートされません。これを行う必要がある場合は、追加のディレクトリを作成して管理する必要があります。もう 1 つの重要な課題として、スケールがあります。階層の基本的なオペレーションとして、特定のオブジェクトの親オブジェクトまたは子オブジェクトを見つける必要があります。その階層を使用して大規模なネストした情報のコレクションを表すことができる場合、この基本的なオペレーションは、オブジェクトの数やネストの深さにかかわらず、可能な限り効率的でなければなりません。従来のディレクトリはスケールが困難で、複数の階層を表すために 2 つ以上のディレクトリを使用する場合、苦労が増すばかりです。 新しい Amazon クラウドディレクトリ 本日、Amazon Cloud Directoryをリリースします。このサービスは、上記で説明したような、厳密に型指定された大量の階層データの保存に焦点を絞ったものです。コスト効率を維持しながら数億個のオブジェクトにスケールする機能により、Cloud Directory はあらゆる種類のクラウドおよびモバイルアプリケーションに最適です。Cloud Directory は、Amazon Cognito や AWS Organizations を含む、他の AWS のサービスで既に利用されている構成要素です。これは AWS 内で非常に重要な役割を果たすため、スケーラビリティ、高可用性、およびセキュリティを考慮して設計されました (データは保管時および伝送中に暗号化されます)。Amazon Cloud Directory はマネージド型サービスであるため、ソフトウェアのインストールやパッチ適用、サーバーの管理、ストレージまたはコンピューティングインフラストラクチャのスケーリングについて考える必要がありません。スキーマを定義し、ディレクトリを作成してから、クラウドディレクトリ API を呼び出してディレクトリへの入力を行うだけです。この API は速度とスケールを実現し、効率的なバッチベースの読み書き関数を持つよう設計されています。ディレクトリの長期間使用できる特性に、運用期間中にサポートする必要があるユースケースのスケールや多様性を組み合わせることで、別の課題が明らかになります。経験によれば、静的スキーマはスケールと新しいユースケースによって生じる変更に対応する柔軟性に欠けることがわかっています。この課題に対応し、ディレクトリを将来にも十分対応できるようにするため、Cloud Directory は変更の余地を明確に残したモデルという概念に基づいて作成されています。新しいファセットを追加して、既存のスキーマを拡張します。これは既存のデータをそのまま残す安全なオペレーションであり、既存のアプリケーションは引き続き予期どおり動作します。スキーマとファセットを組み合わせることにより、同じディレクトリ内で複数の階層を表すことができます。たとえば、最初の階層では組織図をミラーリングするとします。後で、各従業員の追加のプロパティ (2 番目の電話番号またはソーシャルネットワークのハンドルなど) を追跡するために別のファセットを追加できます。その後、同じデータ内で地理指向の階層を作成できます (国、都道府県、建物、フロアー、オフィス、従業員など)。説明したように、AWS の他の部分では既に Amazon […]

2016 年 10 月後半に、著名な DNS プロバイダーが、複数のサービス妨害攻撃で構成された大規模なサイバー攻撃の標的となりました。数千万の IP アドレスからの大量の DNS 参照で構成された攻撃により、多くのインターネットサイトやサービスが北米および欧州のユーザーに対して利用できなくなりました。プリンター、カメラ、家庭用ネットワークゲートウェイ、さらにはベビーモニターといったさまざまなインターネッツ接続デバイスで構成されたボットネットを使用して、この分散サービス妨害 (DDoS) 攻撃が実行されたと考えられます。これらのデバイスは Mirai マルウェアに感染し、1 秒あたり数百ギガバイトのトラフィックを生成しました。多くの企業ネットワークや教育ネットワークは、このような規模のボリューメトリック攻撃を吸収するだけのキャパシティーを持っていません。この攻撃や、それ以前のその他の攻撃を受けて、さまざまなタイプの DDoS 攻撃に対してより弾力性の高いシステムを構築できるようにするための推奨事項やベストプラクティスについてお客様から当社に問い合わせがありました。簡単な回答としては、スケール、耐障害性、および緩和を組み合わせ (詳細については「AWS Best Practices for DDoS Resiliency」ホワイトペーパーを参照)、Amazon Route 53 および AWS Shield を利用することです (詳細については、「AWS Shield – Protect Your Applications from DDoS Attacks」を参照)。 スケール – Route 53 は数多くの AWS エッジロケーションでホストされ、大量の DNS トラフィックを吸収することができるグローバルな対象領域を作成します。Amazon CloudFront と AWS WAF を含むその他のエッジベースのサービスにもグローバルな対象領域があり、大量のトラフィックを処理することができます。 耐障害性 – 各エッジロケーションには、インターネットへの数多くの接続があります。これにより、多様なパスが可能になり、障害の分離と阻止に役立ちます。また、Route […]

アプリケーションの構築における課題の 1 つは、ユーザー認証と管理に関する事柄です。この課題に直面しても、多くの開発者はアプリケーション用の別のユーザー ID と認証システムを構築したいとは考えていませんし、必要な場合を除いてユーザーにさらに別のアカウントを作成させたいとも思っていません。Amazon Cognito では、アプリケーションのデータとバックエンドシステムにアクセスするために、開発者がユーザーの ID、認証、および権限を簡単に管理できるようになっています。それに加えて、開発者がアプリケーションの異なるユーザーに異なる権限を割り当てるのを簡単にするサービス機能があればどんなによいでしょう。本日、Cognito ユーザープールがグループをサポートし、Cognito フェデレーション識別がきめ細かなロールベースのアクセス制御 (RBAC) をサポートするようになったことが発表されました。Cognito でのグループのサポートにより、開発者は異なるユーザータイプとアプリケーションの使用権限を表すグループを作成して、ユーザーのアプリケーションエクスペリエンスを簡単にカスタマイズできます。開発者は、グループからのユーザーの追加や削除、およびユーザーのセットに対してグループで権限を管理できます。権限に関しては、Cognito フェデレーション識別でのきめ細かなロールベースのアクセス制御 (RBAC) のサポートにより、開発者は異なる認証をされたユーザーに異なる IAM ロールを割り当てられます。これまで、Amazon Cognito ではすべての認証されたユーザーに対して 1 つの IAM ロールのみをサポートしていました。きめ細かな RBAC を使用すると、開発者はフェデレーティッドユーザーに異なる IAM ロールをマッピングすることができます。この機能は Facebook や Active Directory などの既存の ID プロバイダーと Cognito ユーザープールを使用したユーザー認証の両方で利用できます。 Cognito ユーザープールのグループ 新しい Cognito のグループの機能について調べる最善の方法は、Amazon Cognito コンソールで新しいグループを作成して、さまざまなグループタイプにユーザーを追加してみることです。   [my user pool]、[TestAppPool] を選択すると、[Users and groups] という更新されたメニュー項目があります。メニューオプションを選択すると、パネルに [Users] と [groups] […]

オンラインの世界は時として不愉快な場所です！あなたがウェブサイトを公開するや否や、問題を起こしたり、サイトを停止させようとする多くの種類の攻撃の標的にされます。DDoS (分散型サービス妨害) 攻撃は非常に一般的な問題の一つです。攻撃者はウェブ上のあらゆる侵害されたリソースを利用し、活動を特定の標的に集中させます。 DDoS攻撃には一般的に3つの種類があります。 アプリケーション層攻撃 はアプリケーションのリソースを消費するように設計された、整形式かつ悪意のあるリクエスト(HTTP GETやDNSクエリが一般的)からなります。たとえば複数のHTTP接続を開き、数秒または数分かけてレスポンスを読むことで、過剰にメモリが消費され、正当なリクエストが処理されなくなります。 State-Exhaustion 攻撃 はステートフルなプロトコルを悪用し、一接続当たりに多くのリソースを消費させることでファイヤーウォールや負荷分散装置に負荷を与えます。 ボリューム攻撃 は対処しきれないほどの大量なトラフィックを送りつけたり、無防備な被害者に驚くほど大量の低レベル”surprise”応答を送りつける偽クエリを発行(別名：リフレクション攻撃)させて、ネットワークを不通にします。 新サービス – AWS Shield AWS Shieldは新しいマネージドサービスで、ウェブアプリケーションをDDoS (分散型サービス妨害) 攻撃から保護します。Elastic Load Balancing、 Amazon CloudFront、Amazon Route 53と連携して動作し、様々なタイプ、形状、サイズの攻撃からお客様を保護します。このサービスには二つのTierがあります。 AWS Shield Standard は追加費用なしで、すべてのAWS顧客が利用できます。 SYN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96％からお客様を守ります。 この保護は、Elastic Load Balancer、CloudFrontディストリビューション、Route 53リソースに自動的かつ透過的に適用されます。 AWS Shield Advanced は、ボリューム攻撃に対する追加のDDoS軽減機能、インテリジェントな攻撃検出、アプリケーションおよびネットワーク層での攻撃に対する軽減を提供します。 攻撃の軽減のカスタマイズ、高度なリアルタイムメトリクスとレポート、DDoS攻撃の影響で請求金額が跳ね上がるのを防ぐDDoSコスト保護のために、私たちのDDoSレスポンスチーム(DRT)に24時間365日アクセスできます。 詳しくは、AWS Shield もしくは Get Started with AWS Shield Advanced をご参照ください。 原文：AWS Shield – Protect […]

先日のブログ「Amazon S3 で IPv6 をサポート」の続報として、今回は Amazon CloudFront、Amazon S3 Transfer Acceleration、AWS WAF と 50 か所以上に渡るすべての CloudFront エッジロケーションでも IPv6 サポートが利用可能になったことをお知らせします。AWS では、すべての自律システムネットワーク (ASN) で IPv6 を有効にするための段階的な移行プロセスを本日より開始し、今後数週間に渡りすべてのネットワークで拡張する予定です。 CloudFront IPv6 のサポート 各 Amazon CloudFront ディストリビューションごとに IPv6 サポートを有効にすることができます。IPv6 を使用して CloudFront エッジロケーションに接続する閲覧者とネットワークは自動的に IPv6 でコンテンツを取得します。IPv4 を使用して接続する場合は以前のように機能します。オリジンサーバーへの接続には IPv4 を使用します。 新たに作成したディストリビューションでは自動的に IPv6 が有効になります。既存のディストリビューションを変更するには [Enable IPv6] を有効にします。これはコンソールまたは CloudFront API から設定できます。 この新機能の重要事項については次をご覧ください。 エイリアスレコード – ディストリビューションで IPv6 サポートを有効にすると、ディストリビューションの […]

AWS Key Management Service (KMS) は暗号鍵のシームレスな中央集中管理を提供します。私達のお客様は、鍵管理インフラストラクチャ(KMI)に関する、可用性、スケーラビリティ、物理的なセキュリティ、ハードウェアメンテナンスを自動的にハンドルするこのフルマネージドなサービスをとても気に入っています。また、KMSは、作成、ローテーション、ライフサイクル管理機能を持つ一つのダッシュボードで鍵管理を集中化します。初期費用無し、カスタマーマスターキー(CMK)1つ当たり月額＄1の利用価格をベースとして、KMSは、S3, EBS, RDS, Redshift, およびその他のKMSとインテグレートされたAWSサービス内に保管されたデータを容易に暗号化することが出来ます。 多くのAWSのお客様は、鍵を作成して管理するのにKMSを利用しています。しかしながら、KMSが提供するその他の機能を活用しながら、鍵に対するローカルコントロールを維持したいというお客様がいらっしゃいます。お客様は私たちに、世代や鍵の保管場所に関するローカルコントロールは、よりセンシティブなワークロードをクラウドで稼働させるためのセキュリティとコンプライアンス要求を満たすのに役立つと仰っています。 Bring Your Own Keys  このような重要なユースケースをサポートするために、本日、KMSにユーザー独自の鍵を持ち込むことが可能になったことを発表できることを嬉しく思います。この機能により、極めてセンシティブなワークロードが保護でき、AWSの外に鍵のセキュアなコピーを保持することが可能になります。この新しい機能により、RSA PKCS #1標準をサポートする全ての鍵管理およびHSM(Hardware Security Module)ソリューションからの鍵のインポートが可能になり、その鍵をAWSサービスおよびアプリケーションから利用することが可能になります。また、KMSは詳細な監査情報を提供するためにAWS CloudTrailと協調して動きます。全てをまとめると、高可用性を提供するためにAWSを利用すれば、鍵のライフサイクルと耐久性に強大なコントロールを得ることができます。今日のほとんどの鍵管理ソリューションはHSMをバックエンドに使っていますが、全てのHSMが鍵管理ソリューションを提供するわけでは有りません。 インポートプロセスは、AWSマネージメントコンソールを使う,  AWS CLIを使う,  あるいは KMS APIをコールすることによって開始できます。オープンな環境に秘密鍵を転送させないために、インポートプロセスでは、アカウントにユニークな、KMSによって提供される公開鍵を使って、事前にユーザーのKMIの鍵をラップすることが求められます。鍵をラップするために、PKCS #1 スキームを利用することができます。 私は、Importing Key Material in AWS Key Management Serviceの指示に従って、KMSコンソールでCreate keyをクリックすることから始めます: エイリアスと説明を入力し、外部(External)を選択し、“I understand…”チェックボックスにチェックを付けました: それから、鍵管理のためのKMS APIを許可するIAMユーザーのセットを選びます。(このステップは、次に行うようにKMSおよび外部キーの両方に適用されます。): 次に、鍵を使ってデータの暗号化/復号化ができるIAMユーザーのセットを選択します: キーポリシーを確認し、ラッピングキーとインポートトークンをダウンロードしました。ラッピングキーは、私がKMSにインポートして使おうとしている256bitの秘密鍵を暗号化するのに利用する2048bitのRSA公開鍵です。インポートトークンは、私の鍵をKMSに正しくインポートさせるためのメタデータを含んでいます。 ZIPファイルを展開し、ラッピングキーを私のEC2インスタンス上のディレクトリ上に配置しました。それから、opensslコマンドを2度使いました:一度目は秘密鍵を生成するためで、2度目はその秘密鍵をラッピングキーでラップするためです。インポートする256bit鍵を生成するためにopensslを便利な方法で利用している事に注目してください。本番データ用としては、鍵の生成と保管にもっとセキュアな方法(商用の鍵管理やHSMソリューションが望ましい)を利用すべきです。 $ openssl rand -out plain_text_aes_key.bin 32 $ openssl rsautl -encrypt -in plain_text_aes_key.bin -oaep \ -inkey wrappingKey_fcb572d3-6680-449c-91ab-ac3a5c07dc09_0804104355 \ -pubin -keyform DER -out enc.aes.key 最後に、“I am ready to upload…”をチェックしてNextをクリックし、鍵の有効期限と共に鍵マテリアルを指定して、全ての情報が集まります。有効期限を過ぎた後はAWSから利用できなくなるので、要件がはっきりするまで有効期限無しのオプションを選択したいと考えるかもしれません。いつでも同じ鍵を再インポートして、有効期限を後からリセットすることができます。 Finishをクリックして、鍵が有効化され利用できるようになりました: […]

数か月前公開したブログ Amazon Cognito の新しい Your User Pools 機能についてご紹介しました。その時点では、ユーザーのモバイルアプリやウェブアプリでサインアップやサインインに同機能を使用することをご説明しました。完全マネージド型のユーザーディレクトリでは、ユーザー数億人の拡大を可能にしたり、各 AWS アカウントで複数のディレクトリを使用することができます。ユーザープールは数分で作成でき、新規ユーザーがお客様のアプリまたはサービスにサインアップする時に、どの属性 (アドレス、メール、性別、電話番号やカスタム属性など) に入力の必要があるか指定することができます。セキュリティの面では、お好みに合わせたパスワード強度を特定したり、Multi-Factor Authentication (MFA) の使用の強制やユーザーの電話番号またはメールアドレスでの確認を求めることができます。 一般提供を開始 Your User Pools のパブリックベータ版を開始したところ、数多くの素晴らしいフィードバックをいただきました。そして本日、Your User Pools の一般公開を開始した他、このリリースに伴い、いくつかの新機能も追加しました。 Device Remembering – Cognito は各ユーザーがどのデバイスからサインインしたか記憶することができます。 User Search – 属性に基づきユーザープールでユーザーを検索できます。 Customizable Email Addresses – ユーザープール内でユーザーのメールアドレスを管理できます。 Attribute Permissions – 各ユーザーの属性を細かく設定することができます。 Custom Authentication Flow – 新たな API や Lambda トリガーを使用してサインインフローをカスタマイズできます。 Admin Sign-in – バックエンドサーバーや Lambda […]

私の同僚である Eric Fitzgerald による次の記事は、AWS Lambda 関数を使用して Amazon Inspector による評価結果をお客様のチケット発行システムやワークフローシステムに転送する方法についてご説明しています。 — Jeff AWS Re:Invent 2015 にて、セキュリティ脆弱性評価サービスの Amazon Inspector をご紹介しました。同サービスは、お客様が早期かつ頻繁にセキュリティ脆弱性テストを実施できるようにサポートするものです。Amazon Inspector をご利用いただくと、お客様は開発環境、テスト環境、実稼働環境でセキュリティテストを自動化することができます。セキュリティ脆弱性をソフトウェア開発、デプロイ、運用ライフサイクル全体の一部として識別します。Amazon Inspector の自動セキュリティテストは、お客様から非常に高く評価されています。Amazon InspectorAnalyze Application Security により、セキュリティ評価を今まで以上に頻繁に実行できるようになったほか、以前に比べセキュリティ脆弱性の早期発見に繋がったと報告を受けています。けれども、セキュリティ脆弱性を識別するだけでは完全といえません。脆弱性を発見したら問題を修正する必要があります。多くのお客様は Amazon Inspector による評価結果に対応するためのワークフローを自動化そして加速するために、Amazon Inspector を自社のワークフローシステムやチケット発行システムと統合しています。Amazon Inspector はそうしたポイントを念頭にを設計しているので、Amazon Inspector による評価結果をメールやワークフローシステムまたはチケット発行システムで統合する方法のひとつを詳しくご説明することにいたしました。 AWS Lambda を使用して Amazon Inspector による評価結果をチケット発行システムにプッシュする この例では AWS Lambda 関数を使用して、メール経由で作成するインシデントに対応できるシステムに Amazon Inspector を接続します。イベントのフローは次のとおりです。 Amazon Inspector が実行しセキュリティ評価を行います。実行終了前に Amazon Simple Notification Service […]

Amazon Cognito を使うことでバックエンドコードを書いたり、インフラストラクチャの管理をする必要なくモバイルや Web アプリに簡単に認証やユーザ管理とデータ同期を簡単に追加できます。ユーザごとの設定やアプリケーションの状態データをバックエンドコードを書いたり、インフラストラクチャの管理をする必要なく AWS Cloud に保存することが簡単になります。昨年、AWS CloudTrail サポートやログインプロバイダとして Twitter および Digits の使用、Cognito におけるイベントに応答するAWS Lambda function の実行機能、そして Amazon Kinesis へのユーザアイデンティティデータのストリーミングといったいくつかのパワフルな新機能を Cognito に追加しました。 User Pools モバイルと Web アプリに簡単にユーザサインアップとサインインを追加するのに Amazon Cognito を利用できるようになりました。User Pool の機能を用いて、数億ユーザまでスケールし、フルマネージドなので構築したり、セキュアにしたりアプリに対する認証をスケールしたりするのに関連する重労働について心配することなく独自のユーザディレクトリを作成できます。この機能は email による確認、電話番号による確認や多要素認証といった拡張されたセキュリティ機能も提供します。アプリ開発者として、みなさんはこういった目的のために、Federated Identity Pools と呼ぶようになった Cognito の機能を利用して、Amazon、Facebook、Google、Twitter もしくは Digits といった外部のアイデンティティプロバイダを利用するというオプションを既に持っていました。User Pool を使うことで Web とモバイルの SaaS アプリ、ゲームなどといった面でサインアップとサインインに詳細なコントロールが可能になります。あらゆるスケール（潜在的には数十や数億のユーザ）でディレクトリサービスを構築し稼働させることは簡単ではなく、ユーザ名、パスワード、email アドレスやその他のセンシティブな情報のかけらを管理するときに追加されるセキュリティの重荷とともに全くもって付加価値を生まない重労働です。User Pool を使う場合、独自のディレクトリサービスを構築し、稼働させる必要はありません。 アカウントごとの複数のUser Pool 自分の […]