Amazon Web Services ブログ

Category: Security, Identity, & Compliance

Cloud Directory の更新 – Typed Links のサポート

今年始めに公開したブログ「Cloud Directory – 階層データの AWS クラウドネイティブディレクトリ (Cloud Directory, our cloud-native directory for hierarchical data)」では、厳密に型指定された入力の階層データを大量保存できるように設計された方法について説明しました。Cloud Directory は何百万というオブジェクトを保存するようにスケールできるので、様々なクラウドアプリケーションやモバイルアプリケーションに最適です。最初のブログ投稿では、どのようにして各ディレクトリに 1 つ以上のスキーマがあるか、そしてそれにより 1 つまたはそれ以上のファセットがあるかについて説明しました。各ファセットは、オブジェクトの必須の属性および許容される属性の一連を定義します。 Typed Links の概要 本日より、Typed Links のサポートを追加することで Cloud Directory モデルの表記枠を拡大しました。次のリンクを使用して複数の階層に渡りオブジェクトとオブジェクトの関係を作成できます。ディレクトリにある複数のタイプのリンクをそれぞれ定義することができます (各リンクの種類はディレクトリと関連付けているスキーマ 1 つの個別ファセットです)。タイプの他に、各リンクには一連の属性を与えることができます。Typed Links は、他のオブジェクトと関係する既存のオブジェクトを不注意に削除しないようにすることで、参照データの整合性を維持する上で役立ちます。たとえばロケーション、ファクトリー、フロア番号、ルーム、マシン、センサーなどのディレクトリがあるとします。こうした情報はそれぞれ階層内で豊富なメタデータ情報を含む Cloud Directory のディメンションとして表示することが可能です。Typed Links を定義し使用することで、様々な方法でオブジェクトを連携させたり、メンテナンス要件に繋がる Typed Links の作成、サービス記録、保証、安全情報などをリンクの属性を使用してソースオブジェクトと対象オブジェクト間の関係の追加情報を保存できます。そしてリンクタイプや属性の値をベースにクエリを実行することができます。たとえば、過去 45 日以内に消去されていないすべてのセンサーや、保証期間が過ぎたモーターをすべて探すことができます。指定されたフロアにあるすべてのセンサーを探したり、指定されたタイプのセンサーがあるフロアすべてを探すことができます。 Typed Links を使用する Typed Links を使用するには、1 つ以上の Typed Link ファセットをスキーマに追加します。追加するには CreateTypedLinkFacet関数を呼び出します。次に […]

Read More

ランサムウェア「WannaCry」に関するAWSへの影響について

  2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。 このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。   WannaCryによるAWSサービスへの影響   EC2 Windows   Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。 AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。 AWSのWindows AMIのリリースノートはこちらです。   WorkSpaces   Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。   Directory Service   AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。   Elastic Beanstalk   […]

Read More

Amazon Inspector の更新 – 評価レポート、プロキシサポートなど

は当社の自動セキュリティ評価サービスです。このサービスは AWS で実行するアプリケーションの動作を分析し、セキュリティ問題を識別する上で役立ちます。Inspector については 2015 年の後半にこのブログで紹介し、その使い方についてご説明したことがあります (「Amazon Inspector – 自動セキュリティ評価サービス (Amazon Inspector – Automated Security Assessment Service)」)。同サービスを使うには、まずタグを使用してアプリケーションを生成する AWS リソースのコレクションを定義します。次に、セキュリティ評価テンプレートを作成し評価の一部として実行したい一連のルールを特定します。 評価ターゲットとセキュリティ評価テンプレートを作成したら、クリック 1 つでターゲットリソースに対して実行することができます。この評価は Linux と Windows ベースの EC2 インスタンスで実行するエージェントを活用します (詳細については「AWS エージェント (AWS Agents)」をご覧ください)。評価は手動で実行したり、 を使用して既存の発券システムに結果を転送することができます (手順については「Amazon Inspector でセキュリティ脆弱性テストをスケールする (Scale Your Security Vulnerability Testing with Amazon Inspector)」をご覧ください)。実行するインスタンスが 1 件または何千件とある場合でも、定期的かつ頻繁に評価を行うことをおすすめします。デプロイや統合インスタンスといった DevOps パイプラインの一部として実行できます。そうすることで、セキュリティ評価テンプレートの作成時に選択したルールパッケージによる条件に見合った本稼働環境で、コードやシステムを安心してデプロイすることが可能になります。また、設定ドリフトを回避するため、本稼働システムに対しても頻繁に評価を実行することをおすすめします。Amazon Inspector には、次の強力な新機能を追加したばかりです。 評価レポート – 新しい評価レポートはエグゼクティブサマリーから始まり、評価の総合的な概要を提供します。このレポートはチームやリーダーシップとの共有そしてコンプライアンス監査のドキュメントとしても使用できるように作成されています。 プロキシのサポート – […]

Read More

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。 Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL […]

Read More

AWS KMSを使用してAmazon Kinesisレコードを暗号化および復号する

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。 Amazon Kinesisの概要 Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。 Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され(最大168時間まで延長可能)、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。 ウォークスルー Amazon Kinesis Producer Library(KPL)、Kinesis Consumer Library(KCL)、AWS KMS、aws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります: AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。 Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。 アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。 次の図は、ソリューションのアーキテクチャを示しています。

Read More

AWS Organizationsを利用したアカウント作成の自動化

こんにちは、ソリューションアーキテクトの千葉です。 本日はを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。 AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。 AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。 AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、やを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。 それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。   メンバーアカウントの作成 まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “organizations:*” ], “Resource”: [ “*” ] } ] } CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。 import boto3 orgs = boto3.client(‘organizations’,region_name=’us-east-1′) createAccountRequest = orgs.create_account( “AccountName”: “string”, “Email”: “string”, “IamUserAccessToBilling”: “string”, “RoleName”: “string” ) […]

Read More

AWS Microsoft ADとオンプレミスの資格情報を使用してAWS管理コンソールにアクセスする方法

これは、AWS Security blogに投稿された「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」の翻訳記事です。   AWS Microsoft ADと略される、AWS Directory Service for Microsoft Active Directory は、AW​​Sクラウドにホストされた管理されたMicrosoft Active Directory(AD)です。オンプレミスのAD管理ツールを使用して、AWSリソースを管理する権限をユーザに簡単に付与できます。AWS Microsoft ADを使用すると、Identity and Access Management(IAM)を利用してAWSリソースへのアクセス管理をしたり、セキュリティアサーションマークアップ言語(SAML)でADフェデレーションサービス(AD FS)を構成する代わりに、オンプレミスユーザーにAWS管理コンソールなどのリソースへのアクセス許可を与えることができます。 このブログ記事では、AWS Microsoft ADを使用してオンプレミスのADユーザーがオンプレミスのADユーザー資格情報を使用してAWS管理コンソールにサインインし、IAMロールを通じてAWSリソースにアクセスして管理する方法を示します。   概要 AWSのお客様は、オンプレミスADを使用してユーザーアカウントを管理し、グループメンバーシップを管理し、オンプレミスリソースへのアクセスを制御します。 多くのAWS Microsoft ADのお客様がいる場合は、オンプレミスのAD資格情報を使用してAWS管理コンソールにサインインして、 Amazon EC2 、 Amazon RDS 、 Amazon S3などのAWSリソースを管理できるようにすることもできます。 このようなサインインパーミッションを有効にすると、主に4つの利点があります。 オンプレミスのADグループ管理者は、IAMの代わりに標準のAD管理ツールを使用して、AWSリソースへのアクセスを管理できるようになります。 […]

Read More

AWS Organizations – 複数の AWS アカウントのポリシーベースの管理

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

Read More

Amazon クラウドディレクトリ – 階層データ用のクラウドネイティブなディレクトリ

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

Read More

Amazon Route 53 および AWS Shield を使用した DDoS リスクの軽減

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

Read More