Category: General


サーバレス JavaScript アプリケーションで SAML: Part I

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。

このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。


SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。

エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。

この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito のユーザプールと認証連携させ、独自のマネージドユーザディレクトリを作成することもできます。

例えば、ユーザが Active Directory Federation Services (ADFS) で認証する事ができる JavaScript アプリケーションを構築したいかもしれません。ユーザは AWS 認証情報で許可された範囲で API を呼び出して得た情報をアプリケーションに表示させたり、DynamoDB テーブルに書き込むことができます。AWS Mobileブログの記事「Announcing SAML Support for Amazon Cognito」では、新しい SAML 機能について Java、Android、iOS のサンプルコード付きで紹介しました。この記事では、ADFS フローのカスタマイズについて JavaScript のサンプルを交えて詳細に紹介します。

シナリオ

この記事では、クライアント側のフローを紹介します。SAML アサーションは Amazon API Gateway 経由で渡され、ブラウザ上のコードは Amazon Cognito Identity から直接認証情報を受け取ります。次回のブログ記事では、バックエンド側の処理を紹介します。SAML アサーションと認証情報は、AWS Lambda ファンクション内で処理でき、ビジネスロジックを実現するようカスタマイズしたり監査履歴を取ったりする事ができます。

このシナリオの全コードは SAM テンプレート含め、GitHub の samljs-serverless-sample レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。

サーバレスのアーキテクチャとなっていますが、ADFS との連携は従来のコンピュート サービスである EC2 インスタンスのようなコンポーネントで置き換えることもできます。ADFS の用語や定義については「Claims-based identity term definitions」を参考にして下さい。

前提条件

このブログ記事では、ADFS が動作している環境が必要です。以下の事を実施して下さい。:

  1. AWS コンソールで ADFS との認証連携を設定。「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」を AWS CloudFormation テンプレートと共に参考にしてください。
  2. サインインページ(https://localhost/adfs/IdpInitiatedSignOn.aspx)からユーザ example\bob が ADFS-Dev と ADFS-Production の両方のグループとして認証出来ることを確認します。
  3. Amazon Cognito Identity のプールを作成します。

ADFS 設定の概要

チュートリアルを始める前に、幾つか AWS と SAML の設定を確認しましょう。まず、前提条件にある通り IAM ロールが作成されているかから確認して下さい。アプリケーション用に新しく IAM ロールと AD グループを作成してもかまいません。この記事では、「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」の記事の通り ADFS-Dev と ADFS-Production を利用します。

  1. IAM コンソールで、ロールを選択し ADFS-Ddev を選択し、信頼関係 (Trust Relationships) のタブを開き、以下のコードのようになっている事を確認します。:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::YOURACCOUNTNUMBER:saml-provider/ADFS"
          },
          "Action": "sts:AssumeRoleWithSAML",
          "Condition": {
            "StringEquals": {
              "SAML:aud": "https://signin.aws.amazon.com/saml"
            }
          }
        }
      ]
    }

このポリシーは “ADFS” という SAML IdP で認証されたユーザがロールを引き受ける事を許可しています。また、ポリシーには条件が含まれており、SAML アサーション内の AudienceRestriction が https://signin.aws.amazon.com/ である事となっています。SAML アサーションは ADFS から AWS に HTTP POST で SAMLResponse というヘッダとして送られて来ます。前提条件に記載されている設定が実施済みであれば、ADFS コンソールでは以下のように設定されており、利用者(Ralying Party)の URL として AWS メタデータ URL が指定されています。詳細については、「認証レスポンスの SAML アサーションを設定する」を確認して下さい。



認証後、ADFS は利用者のアプリケーションに自動的にリダイレクトします。

上記のスクリーンショットでは、認証後の SAMLResponse の値を見るために Chrome を利用しました。「トラブルシューティングのためにブラウザで SAML レスポンスを表示する方法」に記載されているとおり、他のブラウザでも同様のことを行えます。SAMLResponse を貼り付ければ、Audience、Roles や Destination などの値を見ることができる “SAML Decoder” がインターネット上にあります。パート 2 のブロク記事では、これをプログラムで行う方法を紹介します。

ADFS からサーバレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

この1つ目のブログのシナリオの方が難しくありません。多くの組織での要件にベストな流れとなっています。ユーザは ADFS で認証して Amazon Cognito から AWS 認証情報を受け取り、アプリの中でアクションを行えます。このサンプルアプリケーションは:

  1. ADFS で認証するログイン メカニズムを変更して取り出すことで、SAMLResponse ヘッダを取り出します。ユーザが S3 上に配置されたウェブサイトを訪問した際に、自動的にこの仕組みが行われます。
  2. ADFS-Dev ロールの信頼ポリシーを変更し、Active Directory の AWS-gDev グループのメンバであれば Amazon Cognio から一時的な認証情報を受け取れるようにします。
  3. ユーザのロールを選択するコードをアプリケーションの中に組み込みます。このブログ記事では、ADFS-Dev ロールを選択します。

参考までに、AWS Console への認証連携の場合 #3 と同様の内容は、ADFS のウェブページ IdpInitiatedSignOn.aspx からリダイレクトされた後にラジオボタンでロールをクリックして選択する事で実現されます。より詳しい内容については、セキュリティブログの「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」をご覧下さい。もしユーザが 1 つの Active Directory グループのメンバだけであれば、SAMLResponse には複数のロールが含まれておらず、その場合は #3 は省略されます。構成は以下の図のとおりとなります。

チュートリアル: ADDFS からサーバーレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

まず、サーバレス Web サイトをセットアップし、認証情報を取得するログインフローを開始させます。シングル Web アプリを配置するのには S3 を使用します。

S3 バケットの作成

  1. S3 のコンソールで、「バケットを作成」を選択して一意なバケット名を入力します。以下の例では “serverlessweb” としますが、皆様は何か他の名前として下さい。
  2. バケットを作成後、詳細設定のページで「プロパティ」を選び、「バケットポリシーの編集」をクリックします。
  3. 以下のポリシーを設定して下さい。YOURBUCKETNAMEGOESHERE は置き換えて下さい。このポリシーは、バケットに入っている HTML や JavaScript などのファイルを誰でも GET リクエストを行えるようにします。Web サイトにアクセスすると Web ブラウザは GET リクエストを発行し、このポリシーがリソースの読み込みをユーザに許可します。
    {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "PublicReadForGetBucketObjects",
              "Effect": "Allow",
              "Principal": "*",
              "Action": "s3:GetObject",
              "Resource": "arn:aws:s3:::YOURBUCKETNAMEGOESHERE/*"
          }
      ]
    }
  4. 「静的ウェブサイトホスティング」を選択し、「ウェブサイトのホスティングを有効にする」とします。フォームに「index.html」と「error.html」を入力します。

  5. 次に、HTML ファイルをバケットに追加して、https://YOURBUCKETNAME.s3-website-REGION.amazonaws.com をブラウザで開きページが見れるか確認します(YOURBUCKETNAME と REGION は読み替えて下さい。)。まずは以下の HTML をテンプレートとして使って下さい。
    <!DOCTYPE html>
    <html>
     <head>
      <title>
       Amazon Cognito SAML Example
      </title>
      <script src="aws-sdk.min.js">
      </script>
     </head>
     <body>
      <h1>
       Testing SAMLResponse
      </h1>
     </body>
    </html>
      
  6. JavaScript SDK から圧縮(Minify)されたバージョン aws-sdk.min.js をダウンロードして、HTML ファイルと同様にバケットに保存し、エラー無くロードできることを確認します。

(オプション) CloudFront ディストリビューションのセットアップ

次に進める前に、さらにもう1つセットアップしたいと思います。CloudFront ディストリビューションです。S3 静的 Web ホスティングに CloudFront やその他の CDN を使用することで、独自ドメイン名で SSL を使用することができるようになります。

API Gateway から HTTP サイトにリダイレクトする事もできるため強制ではありませんが、Web サイトや認証や認可のシステムはエンドツーエンドで HTTPS を使うべきです。以下がセットアップで行う内容です。

  1. CloudFront コンソールで、Web タイプのディストリビューションを作成します。
  2. 「Viewer Protocol Policy」には、「HTTPS Only」を選択します。
  3. 「Origin Domain Name」には S3 バケットを選択します。
  4. ベストプラクティス通り、「Restrict Bucket Access」を選択します。こうすることで、バケットが直接アクセスされることから守ることができます。これで CloudFront ディストリビューションのドメイン名で、サイトにアクセスできるようになると思います。

ログイン メカニズム

次に、ログイン メカニズムを構築します。

ウェブサイトではログインさせるために、ボタンを押させることも出来ますし、自動的に認証情報が有効かどうか確認してからログインのフローにリダイレクトをさせる事もできます。

この例では、2 つ目のアプローチを取ります。ユーザがページを訪れると JavaScript を使ってすぐに状態を確認し、初回の訪問であれば認証情報を入手するためにリダイレクトさせます。このページにはログインの流れの中で API Gateway から再度リダイレクトされても来るため、ログインの進捗に合わせ ADFS のログインページにリダイレクトさせるのと同様に、届いた SAMLResponse のデータをキャプチャする事も必要です。今回の例では、以下のような流れになります。:

function loginWorkflow(){
    var activelogin = sessionStorage.getItem('activelogin');
    if (activelogin=='inProgress'){                                   //ADFS login redirect from API Gateway
        var samlResponse = getParameterByName('SAMLResponse');
        sessionStorage.removeItem(‘activelogin’);
        if (samlResponse != null){
            getSamlCredentials(samlResponse.replace(/\s/g, ''));
        }
    }
    else if (activelogin === null) {                                 //First page visit. Redirect to ADFS login.
        var RPID = encodeURIComponent('urn:amazon:webservices');
        var result = 'https://localhost/adfs/ls/IdpInitiatedSignOn.aspx' + "?loginToRp=" + RPID;
        sessionStorage.setItem('activelogin', 'inProgress');
        window.location = result;
    }
    else {//Credentials exist, page refresh, etc.
        console.log('activelogin already exists in session and the value is ' + activelogin);
    }
}

上記では、ADFS IdP への呼び出しを始める時にセッション変数を設定し、SAMLResponse (getParameterByName() で取り出せる)と一緒にWeb サイトに戻って来た時には getSamlCredentials() 関数を呼び出します。

AWS が必要とする SAMLResponse 値は POST binding のみがサポートされていますが、S3 の静的ウェブサイトは、GET リクエストしか受け取ることができません。このため、JavaScript アプリケーションが ADFS からの SAMLResponse を受け取るために API Gateway を利用します。Lambda をプロキシとして利用し、SAMLResponse をクエリ文字列に入れて静的ウェブサイトにリダイレクトで戻ってこさせます。

Lambda 関数の設定

  1. Lambda のコンソールで、GitHub レポジトリにある /Scenario1/lambda/redirect/index.js を使って samlRedirect という名前の関数をランタイムは Node.js 4.3 で作成します。実行ロールにはログ保存のために CloudWatch Logs の権限だけが必要です。
  2. 基本的な実行ロールが既になければ、関数作成時に新しいロールを Lambda のコンソール上で作成する事ができます。
  3. LOG_LEVELREDIRECT_URL という名前の環境変数を作成し、LOG_LEVEL には info を REDIRECT_URL には S3 の静的ウェブサイトの URL(静的ウェブホスティングを有効にしている場合にはバケットのプロパティに表示されているエンドポイント、あるいは先程記載したオプションの CloudFront ディストリビューション設定をした場合はドメイン名)を設定します。

API Gateway 設定

  1. API Gateway のコンソールで、SAMLAuth あるいは何か似た名前を付けた API を作成します。
  2. リソース」 を選択し、「SAML」という名前の子リソースを作成します。
    lambdasamlone_7.png
  3. POST」メソッドを作成します。「統合タイプ」には「Lambda」を選択し、「samlRedirect」関数を指定します。「メソッドリクエスト」の「HTTP リクエストヘッダー」に「SAMLResponse」を設定します。
    lambdasamlone_8.png

先ほど作成した samlRedirect 関数では、クエリ文字列に SAMLResponse を付けた静的ウェブサイトの URL を location プロパティに設定します。リダイレクトが実行されるように、API Gateway が 302 ステータスコードを返すように設定します。

  1. メソッドレスポンス」でステータスコード 200 を削除し、302 を追加します。「レスポンスヘッダ」に「Location」を設定し、「レスポンス本文」には「コンテンツタイプ」に「application/json」、「モデル」に「Empty」と設定します。
    lambdasamlone_9.png
  2. 「統合レスポンス」で「メソッドレスポンス」のステータスが 200 のものを削除し、302 のものを追加します。レスポンスヘッダ「Location」の「マッピングの値」には「integration.response.body.location」を設定します。
    lambdasamlone_10.png
  3. Lambda 関数が SAMLResponse と RelayState を受け取れるように、「統合リクエスト」で「コンテンツタイプ」が 「application/x-www-form-urlencoded」の「本文マッピングテンプレート」を以下のように追加します。:

    {
    "SAMLResponse" :"$input.params('SAMLResponse')",
    "formparams" : $input.json('$')
    }
  4. 変更を保存します。
  5. /saml リソースで「アクション」から「CORS の有効化」を選択します。「CORS を有効にして既存の CORS ヘッダを置換」を行いします。

  6. アクション」から「API のデプロイ」を選択します。「ステージ」には「Prod」や似た名前を使用します。「ステージエディター」で、「SDK 生成」を選択します。「プラットフォーム」には「JavaScript」を選択し、「SDK の生成」を行い、どこかのフォルダに保存します。ADFS の設定に必要になるため、トップに表示されている「URL の呼び出し」をメモします。

ADFS リダイレクト設定

  1. ADFS のコンソールで、「利用信頼関係」にある Amazon Web Services のプロパティを開き、「利用者を自動的に更新する」の項目を無効(チェックしない)にします。
    lambdasamlone_11.png
  2. エンドポイント」のタブを開き、既にあるエンドポイントを編集します。「バインディング」は「POST」のままで、「URL」には API Gateway でデプロイした API の「URL の呼び出し」を入力します。URL の最後に 「/saml」を追加します。
    lambdasamlone_12.png
    これまで構築してきたことを復習します。:

    • Web ページはユーザが認証情報を持っていなければ、ADFS のログインページにリダイレクトします。
    • 認証に成功したら、ADFS は SAMLResponse を付けて Web ページにユーザを戻します(API Gateway 経由)。
    • SAMLResponse は元の Web ページにクエリ文字列の一部として渡されます。

    Amazon Cognito から認証情報を取得するには、JavaScript コードでこのクエリ文字列を取り出し getCredentialsForIdentity 呼び出しのパラメータの一部として渡す必要があります。

  3. Amazon Cognito の Federated Identities のコンソールで、前提条件でセットアップした認証プールを開きます。認証プールの ID を確認し、以下の JavaScript コードの先頭に利用するリージョン名と同様に記載します。
    const identityPool = 'YOURCOGNITOPOOLID';
    AWS.config.region = 'COGNITOREGION'; // Region
    
    AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: identityPool
    });
    
    var identityId = localStorage.getItem('cognitoid');
    if (identityId != null){
        console.log('Identity ID: ' + identityId);
        loginWorkflow();
    } else {
        console.log('Calling GetID');
        AWS.config.credentials.get(function(){
            console.log('Identity ID: ' + AWS.config.credentials.identityId);
            localStorage.setItem('cognitoid', AWS.config.credentials.identityId);
            identityId = localStorage.getItem('cognitoid');
            loginWorkflow();
        });
    }

このコードは、アプリケーションでユーザに Amazon Cognito で生成した一意の ID を付与する最初の部分です。その上で、クエリ文字列に SAMLResponse の値を入れて返させるために loginWorkflow() を呼び出します。

以下は Stack Overflow で紹介されているサンプルのユーティリティ関数で、クエリ文字列から特定の項目を取り出すためのものです。

function getParameterByName(name, url) {
    if (!url) {
      url = window.location.href;
    }
    name = name.replace(/[\[\]]/g, "\\$&amp;");
    var regex = new RegExp("[?&amp;]" + name + "(=([^&amp;#]*)|&amp;|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));
}

これで Web ページは ADFS から BASE64 エンコードされた SAMLResponse を取得しました。これを Amazon Cognito に渡せば AWS 認証情報を取得することが出来ます。Cognito の getSamlCredentials() 関数は以下のコードで、loginWorkflow() から呼び出されます。:

function getSamlCredentials(samlResponse) {
    var role = 'arn:aws:iam::ACCOUNTNUMBER:role/ADFS-Dev';
    var params = {
        IdentityId: identityId,
        CustomRoleArn: role,
        Logins: {
            'arn:aws:iam::ACCOUNTNUMBER:saml-provider/ADFS' : samlResponse,
        }
    };

    cognitoidentity.getCredentialsForIdentity(params, function(err, data) {
        if (err) console.log(err, err.stack);
        else {
            console.log('Credentials from Cognito: ');
            console.log(data.Credentials);
        }
    });
}

ARN にある ACCOUNTNUMBER は2つとも書き換える必要がある事に注意して下さい。今回は使用するロールがソースに直書きされています。もし、SAML クレームに複数のロールが入って返されないのであれば、このパラメータは省略することもできます。引き受けるロールを何かしらのロジックで選択するようにしたい場合もあると思います。このブログ記事のパート II ではクライアント側ではなくバックエンドでこれをできるようにする内容を含める予定です。

また、logins map にあるキーは IAM コンソールで作成した ADFS の IdP 登録の ARN で、値は samlResponse です。これもアカウント番号に書き換える必要があります。この情報により Amazon Cognito は SAMLResponse の値が信頼している対象の ADFS からのものであるか検証できます。

この時点でこのコードを試しても動作しません。Amazon Cognito の認証プールで、認証プロバイダとして SAML IdP を有効にする必要があります。

  1. Amazon Cognito の Federated Identities のコンソールで、プールを選択し、Authentication Providers までスクロールし、SAML を選択します。ADFS の IdP を示すチェックボックスを選択します。
  2. Save Changes をクリックします。
    lambdasamlone_13.png

次に、Amazon Cognito が有効な SAMLResponse アサーションを受け取った時に、ユーザがロールを引き受けられるように信頼ポリシーを変更します。Amazon Cognito は STSAssumeRoleWithWebIdentity API を呼び出してこれを実現します。

IAM のコンソールで、ADFS-Dev ロールの信頼ポリシーを以下のポリシーに編集します。(JavaScript コードのように適切な位置に Amazon Cognito のプール ID を挿入します。):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "YOURCOGNITOPOOLID"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

これで Amazon Cognito の信頼ポリシーは設定できました。Web ページをテストして下さい。AWS サービスのリクエストへの署名に使える認証情報はコンソールログに (AccessKey, SecretKey, Token) の 3 つが含まれる形で “data” オブジェクトで出力されます。アプリケーションの共通のシナリオは、AWS_IAM 認証に設定された API Gateway のメソッド呼び出しを行うことです。認証情報は SDK のリクエストを使うことで渡す事ができます。上記の呼び出して指定したロールにその API を呼び出す権限があれば、メソッド呼び出しは成功します。

例えば、API Gateway で API を作成した場合、メソッドに AWS_IAM 認証を有効にできます。上記で指定されたロール(logins mapで指定)に、メソッド呼び出しの権限があることを確認して下さい。より詳しいことは、「API Gateway へのアクセスを IAM アクセス権限で制御する」をご覧下さい。API をデプロイした場合、SDK の生成を使ってそのステージの JavaScript SDK を生成してダウンロードできます。これからのメソッド呼び出しを Web ページに組み込む事ができます。より詳しいことは、「API Gateway で生成した JavaScript SDK を使用する」をご覧下さい。トピックの最後に、apigClientFactory.newClient コンストラクタにアクセスキーシークレットキーをどうやって渡すことができるか確認しましょう。

Amazon Cognito Identity は短期間だけ有効な認証情報(1 時間で無効になる)を利用するため、一時的なアクセスキー、シークレットキー、セッショントークンを、apigClientFactory.newClient コンストラクタに渡します。:

        var apigwClient = apigClientFactory.newClient({
        accessKey: data.Credentials.AccessKeyId,
        secretKey: data.Credentials.SecretKey,
        sessionToken: data.Credentials.SessionToken
    });

機能の動作確認ができる Web ページのコードは、GitHub レポジトリ内の /scenario1/website/index.html にあります。同じディレクトリにある configs.js ファイルを更新します。リージョン、Cognito Identity のプール ID、SAML IdP の ARN、ADFS-Dev ロールの ARN を変更します。SAM テンプレートを使って API Gateway に AWS_IAM 認証の MOCK エンドポイントを作成する事もでき、連携された認証情報が機能するか Web ページ上のテストボタンで確認する事ができます。

lambdasamlone_14.png

最後に

チュートリアルを通じて SAML 認証や Amazon Cognito を使った AWS 認証について深いレベルで理解する手助けになる事を願っています。まだ完了していなければ、少し時間をかけて頂き、GitHub レポジトリの samljs-serverless-sample にあるコードを実際に動かし確認して下さい。また感想についても教えてください。

このシナリオは最初のステップとして十分かもしれませんが、組織によってはより多くのことをする必要があるかもしれません。例えば、ロールの選択をユーザに任せたいやビジネスロジックに基づき独自の IAM 範囲を実装したい事もあるかと思います。このシリーズのパート 2 ではこれらをどのようにしたら実現できるかを見ていきたいと思います。

[訳注] このブログで紹介している方法では、ADFS におけるデフォルトの AWS の証明書利用者設定を変更します。そのため、同じ ADFS 環境で AWS のマネージメントコンソールへ認証連携してアクセスさせる事とは同時に実現できません。

原文: SAML for Your Serverless JavaScript Application: Part I (翻訳: SA 辻 義一)

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 EC2Amazon RDSAmazon S3などのAWSリソースを管理できるようにすることもできます。

このようなサインインパーミッションを有効にすると、主に4つの利点があります。

  1. オンプレミスのADグループ管理者は、IAMの代わりに標準のAD管理ツールを使用して、AWSリソースへのアクセスを管理できるようになります。
  2. ユーザーは、ADとAWS Management Consoleにサインインするために1つのIDのみを記憶すればよくなります。
  3. ユーザーはオンプレミスのAD資格情報でサインインするため、AWS管理コンソールへのアクセスには、AD強制パスワードポリシーの量可能になります。
  4. ADからユーザーを削除すると、AWS Microsoft ADとIAMは自動的にAWSリソースへのアクセスを取り消します。

IAMロールは、AWSリソースを管理する権限を定義する便利な方法を提供します。 AWS Microsoft ADとオンプレミスADの間のAD信頼関係を使用することで、オンプレミスのADユーザーとグループをIAMロールに割り当てることができます。 これにより、割り当てられたユーザとグループにAWSリソースを管理するためのIAMロールの権限が与えられます。 オンプレミスのADグループをIAMロールに割り当てることで、ADユーザとコンピュータ(ADUC)などの標準的なAD管理ツールを使用してAWSアクセスを管理できるようになります。

オンプレミスのユーザーやグループをIAMロールに割り当てた後、ユーザーはオンプレミスのAD資格情報を使用してAWS管理コンソールにサインインできます。 そこから、割り当てられたIAMロールのリストを選択できます。 ロールを選択すると、IAMロールに割り当てた管理機能を実行できます。

この記事の残りの部分では、これを4つのステップで達成する方法を示します。

  1. アクセスURLの作成。
  2. AWS管理コンソールへのアクセスの有効化。
  3. オンプレミスのユーザーとグループをIAMロールへの割り当て。
  4. AWS管理コンソールへの接続。

 

前提条件

このブログ記事の指示に従い、次のコンポーネントを実行する必要があります。

  • AWSクラウドで作成されたMicrosoft ADディレクトリ。 詳細については、「Create a Microsoft AD Directory」を参照してください。
  • 既存のオンプレミスActive Directory。
  • AWS Microsoft ADからオンプレミスActive Directoryへの双方向におけるフォレストの信頼関係。 詳細は、「Now Available: Simplified Configuration of Trust Relationships in the AWS Directory Service Console」を参照してください。 信頼に関する追加情報、およびAWS管理コンソールへのドメインレスサインインのアクセス方法については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。
  • AWSディレクトリサービスに設定された信頼関係を持つIAMロール。 これを行うにはヘルプが必要な場合は、「Editing the Trust Relationship for an Existing Role」を参照してください。

注: AWS Microsoft ADに格納されているユーザーIDにIAMロールを割り当てることができます。この記事では、オンプレミスのADに格納されているユーザーIDにIAMロールを割り当てることに重点を置いています。 これには、オンプレミスのActive DirectoryとAWS Microsoft ADディレクトリの間にフォレストの信頼関係が必要です。

 

ソリューションの概要

私が自分の会社のADとIAMロールの両方を管理する管理者だとします。私の会社では、全従業員がオンプレミスの資格情報を使用してAWS管理コンソールにサインインし、AWSリソースにアクセスして管理できるようにしたいと考えています。私の会社はEC2、RDS、S3を使用しています。これらのリソースへの管理権限を管理するために、サービスに完全にアクセスできるように各サービスの権限を作成しました。これらのロールにEC2FullAccess、RDSFullAccess、および、S3FullAccessという名前を付けました 。

私の会社には責任の異なる2つのチームがあり、ADセキュリティグループのユーザーを管理しています。 MaryはDevOpsセキュリティグループのメンバーであり、RDSデータベースの作成と管理、EC2でのデータ収集アプリケーションの実行、S3での情報のアーカイブを担当しています。JohnとRichardはBIMgrsセキュリティグループのメンバーで、EC2を使用してデータベースに対して分析プログラムを実行します。 JohnンとRichardはデータベースとアーカイブされた情報にアクセスする必要がありますが、それらのシステムを操作する必要はありません。EC2インスタンスを管理するための許可が必要です。

AWSリソースへの適切なアクセスを許可するには、ADのBIMgrsセキュリティグループをIAMのEC2FullAccessロールに割り当て、 DevOpsグループを3つのロール(EC2FullAccess 、RDSFullAccess、およびS3FullAccess)すべてに割り当てる必要があります。また、AWS Management Consoleにサインインした後で、従業員全員が十分な管理作業を完了できるようにしたいので、コンソールセッションタイムアウトを60分から240分(4時間)に増やします。

次の図は、私の会社のADユーザーとグループと私の会社のAWSの権限とサービスの関係を示しています。 図の左側は、ユーザーとグループを含む私のオンプレミスのADを表しています。 右側は、AWS管理コンソール、AWSリソース、IAMロール、およびオンプレミスADにフォレストの信頼関係を介して接続されたAWS Microsoft ADディレクトリを含むAWSクラウドを表しています。

 

このシナリオの手順を開始しましょう。この記事では、すでにAWS Microsoft ADディレクトリが作成されており、AWS Microsoft ADからオンプレミスADへの双方向フォレストの信頼を確立しています。AWSリソースへのアクセスを管理するため、以下のIAMロールも作成してあります。

  • EC2FullAccess :EC2へのフルアクセスを提供し、 AmazonEC2FullAccess AWS管理ポリシーを添付します。
  • RDSFullAccess :AWS管理コンソール経由でRDSへのフルアクセスを提供し、 AmazonRDSFullAccess管理ポリシーを添付します。
  • S3FullAccess :AWS管理コンソール経由でS3へのフルアクセスを提供し、 AmazonS3FullAccess管理ポリシーを添付します。

IAMロールを作成して管理ポリシーを添付する方法の詳細については、「管理ポリシーのアタッチ」を参照してください。

注: Microsoft ADを使用してAWS管理コンソールにサインインするユーザーがアクセスする必要があるすべてのロールに、ディレクトリサービス信頼ポリシーを含める必要があります。 詳細は、「Editing the Trust Relationship for an Existing Role」を参照してください。

 

ステップ1 – アクセスURLを作成する

AWS Management Consoleへのアクセスを有効にするための最初の手順は、AWS Microsoft ADディレクトリのための一意のアクセスURLを作成することです。アクセスURLは、グローバルに一意のURLです。AWS管理コンソールなどのAWSアプリケーションは、URLを使用して、AWS Microsoft ADディレクトリにリンクされているAWSサインインページに接続します。 アクセスURLは、ディレクトリへの他のアクセスを提供しません。 アクセスURLの詳細については、「Creating an Access URL」を参照してください。

アクセスURLを作成するには、次の手順を実行します。

 

  1. ディレクトリサービスコンソールに移動し、AWS Microsoft AD Directory IDを選択します。
  2. Directory Detailsページで、Apps & Services タブを選択し 、Access URL ボックスに一意のアクセスエイリアスを入力し、 Create Access URLを選択してディレクトリのアクセスURLを作成します。ディレクトリのアクセスURLは、 <access-alias> .awsapps.comという形式にする必要があります。 この例では、 https://example-corp.awsapps.comを使用しています。

 

ステップ2 – AWS管理コンソールへのアクセスを有効にする

ユーザがオンプレミスの認証情報でAWS Management Consoleにサインインできるようにするには、AWS Microsoft ADディレクトリのAWS管理コンソールアクセスを有効にする必要があります。

  1. ディレクトリサービスコンソールから、AWS Microsoft AD Directory IDを選択します。 AWS apps & servicesセクションのAWS Management Consoleリンクを選択します。
  2. Enable AWS Management Consoleダイアログボックスで、 Enable Accessを選択して、ディレクトリに対するコンソールアクセスを有効にします。

    これにより、AWS Microsoft ADディレクトリのAWS Management Consoleへのアクセスが可能になり、コンソールに接続するためのURLが提供されます。 URLは、ステップ1: <access-alias>.awsapps.com/consoleで作成したアクセスURLの末尾に「 /console 」を付加して生成されます。 この例では、AWS管理コンソールのURLは、https://example-corp.awsapps.com/consoleです。

 

ステップ3 – オンプレミスのユーザーおよびグループをIAMロールに割り当てる

ユーザーがアクセスURLを使用してAWS管理コンソールにサインインする前に、オンプレミスのユーザーまたはグループをIAMロールに割り当てる必要があります。このステップで、オンプレミスのユーザーおよびグループがAWS管理コンソールからアクセス可能なAWSリソースを制御できます。

私のオンプレミスのActive Directoryでは、 Maryは既にDevOpsグループのメンバーであり、JohnとRichardはBIMgrsグループのメンバーです。私はすでにAWS Microsoft ADから私のオンプレミスADへの信頼関係を確立しました。EC2FullAccess 、RDSFullAccessおよびS3FullAccessの権限を作成できました。

これで、オンプレミスグループをIAMロールに割り当てる準備が整いました。私はDevOpsグループをEC2FullAccess、RDSFullAccess 、およびS3FullAccess IAMロールに割り当て、BIMgrsグループをEC2FullAccess IAMロールに割り当てます。オンプレミスグループをIAMロールに割り当てるには、次の手順に従います。

  1. AWS Microsoft ADディレクトリのディレクトリサービスの詳細ページを開き、Apps & servicesタブのAWS Management Console リンクを選択します。 Continue を選択して、 Add Users and Groups to Rolesページに移動します。
  2. Add Users and Groups to Rolesページでは、既に設定した3つのIAMロールが表示されます(次のスクリーンショットを参照)。 ディレクトリサービス信頼ポリシーが有効なIAMロールがない場合は、 新しいロールを作成するか、既存のロールに対してディレクトリサービスを有効にすることができます。
  3. オンプレミスのDevOpsグループとBIMgrsグループをEC2FullAccessロールに割り当てます。これを行うために、私はEC2FullAccess IAMロールリンクを選択して、Role Detailページに移動します。 次に、次のスクリーンショットに示すように、 Addボタンをクリックしてユーザーまたはグループをロールに割り当てます。
  4. Add Users and Groups to Role ポップアップウィンドウで、割り当てるユーザーとグループを含むオンプレミスのActive Directoryフォレストを選択します。 この例では、そのフォレストはamazondomains.comです。 注:オンプレミスADへの信頼を使用せず、AWS Microsoft ADディレクトリにユーザーとグループを作成する場合は、 このフォレストのデフォルトを選択してMicrosoft ADのユーザーを検索できます。
  5. Active Directoryグループを割り当てるには、Search forフィールドの上にあるGroupフィルタを選択します。 検索ボックスにActive Directoryグループの名前を入力し、検索ボタン(虫眼鏡のマークを選択します。 私はオンプレミスのActive DirectoryからDevOpsグループを検索できたことがわかります。
  6. この例では、社内のグループDevOpsとBIMgrsをEC2FullAccessロールに追加しています。終了したら、Addボタンを選択して、ユーザとグループをIAMロールに割り当てます。 これで、DevOpsとBIMgrsオンプレミスADグループにEC2へのフルアクセスが正常に付与されました。これらのADグループのユーザは、自社の認証情報を使用してAWS管理コンソールにサインインし、EC2インスタンスを管理できるようになりました。
    Add Users and Groups to Rolesページから、残りのグループをIAMロールに割り当てるプロセスを繰り返します。次のスクリーンショットでは、DevOpsグループを3つのロールに、BIMgrsグループを1つのロールに割り当てたことがわかります。
    ADセキュリティグループを自分のIAMロールに割り当てることで、オンプレミスユーザーをセキュリティグループに追加および削除して、IAMロールへのアクセス許可を付与または取り消すことができます。これらのセキュリティグループのユーザーは、割り当てられたすべての権限にアクセスできます。
  7. オプションで、AWS Microsoft ADディレクトリのログインセッション長を設定できます。デフォルトの長さは1時間ですが、最大12時間まで延長できます。私の例では、コンソールのセッション時間を240分(4時間)に設定しています。

 

ステップ4 – AWS管理コンソールに接続する

私は、ユーザが自社の認証情報でAWS Management Consoleにサインインできるようになりました。 ステップ2で作成したアクセスURL: https://example-corp.awsapps.com/consoleを自社のユーザーにメールで送信しました。 これで、ユーザーはURLにアクセスしてAWS Management Consoleにサインインできます。

DevOpsグループのメンバーであるMaryがアクセスURLにアクセスすると、AWS Management Consoleに接続するためのサインインページが表示されます。 Usernameボックスでは、3つの方法でサインイン名を入力できます。

  • 社内のNetBIOSログイン名(corp\mary)の指定。
  • 彼女の完全修飾ドメイン名(FQDN)のログイン名( amazondomains.com\mary)の指定。
  • ドメインなしのログインで彼女のユーザー名だけを使用。ドメインレスログインの詳細については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。

DevOpsグループは3つのIAMロールに関連付けられており、MaryはDevOpsグループに属しているため、ログイン後に表示されるリストから希望するロールを選択できます。次のスクリーンショットはこのステップを示しています。

マルチファクタ認証(MFA)を使用してAWS管理コンソールを保護する場合は、AWS Microsoft AD設定にMFAを追加することもできます。 Microsoft ADでMFAを有効にする方法の詳細については、「How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials」を参照してください。

まとめ

AWS Microsoft ADを使用すると、オンプレミスの資格情報を使用してAWS管理コンソールに簡単に接続できます。 また、AWSリソースへのアクセスを制御しながら、パスワード有効期限、パスワード履歴、アカウントロックアウトポリシーなどの社内ADセキュリティポリシーを再利用することもできます。

ディレクトリサービスの詳細については、 AWS Directory Serviceのホームページを参照してください 。 このブログの投稿に関するご質問がある場合は、 ディレクトリサービスフォーラムで新しいスレッドを開始してください。

– Vijay


 

翻訳:瀧澤与一(原文:「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」 – https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/

JSONSerDe によるマッピングを使って,入れ子の JSON から Amazon Athena のテーブルを作成する

多くのシステムでは、イベント情報を記録するのに Java Script Object Notation (JSON) を使っています。JSON は効率的かつ柔軟ではありますが、JSON から情報を取り出すのは面倒です。

この投稿では、ログデリバリー手段としての Amazon Kinesis Firehose、ログ保存先としての Amazon S3、データの加工整形やデータベースへの挿入なしに ログに対して JSONSerDe を使って SQL クエリを投げる手段としての Amazon Athena を、緊密に連携させます。これらの処理は、完全にサーバーレスで行われます。コンピューティングリソースを準備する必要はありません。

Amazon SES を使えば、サービス間の全メッセージに対する詳細なログが入手でき、SES イベント発行によって、それを Firehose でも利用することができます。しかし、トレンドやコンプライアンスのデータに関する詳細ログのパースには、多額のインフラ投資や開発期間が必要となります。Athena は保存されているデータに対して、そのままのフォーマットで、コードを書いたりアーキテクチャ設計をしたりすることなく直接クエリできることにより、こうしたデータ探索に非常に適しています。その上、Athena では多くの標準 SQL クエリとシンタックスが利用可能です。

ウォークスルー: データセットの作成

まず、以下のような SES 送信イベントのデータセットをみてみましょう。

{
	"eventType": "Send",
	"mail": {
		"timestamp": "2017-01-18T18:08:44.830Z",
		"source": "youraddress@example.com",
		"sourceArn": "arn:aws:ses:us-west-2:111222333:identity/youraddress@example.com",
		"sendingAccountId": "111222333",
		"messageId": "01010159b2c4471e-fc6e26e2-af14-4f28-b814-69e488740023-000000",
		"destination": ["success@simulator.amazonses.com"],
		"headersTruncated": false,
		"headers": [{
				"name": "From",
				"value": "youraddress@example.com"
			}, {
				"name": "To",
				"value": "success@simulator.amazonses.com"
			}, {
				"name": "Subject",
				"value": "Bounced Like a Bad Check"
			}, {
				"name": "MIME-Version",
				"value": "1.0"
			}, {
				"name": "Content-Type",
				"value": "text/plain; charset=UTF-8"
			}, {
				"name": "Content-Transfer-Encoding",
				"value": "7bit"
			}
		],
		"commonHeaders": {
			"from": ["youraddress@example.com"],
			"to": ["success@simulator.amazonses.com"],
			"messageId": "01010159b2c4471e-fc6e26e2-af14-4f28-b814-69e488740023-000000",
			"subject": "Test"
		},
		"tags": {
			"ses:configuration-set": ["Firehose"],
			"ses:source-ip": ["54.55.55.55"],
			"ses:from-domain": ["amazon.com"],
			"ses:caller-identity": ["root"]
		}
	},
	"send": {}
}

 

このデータセットには、 SES の送受信に関する多くの価値ある情報が含まれています。インサイトを得るためにパース処理が必要な、同じ形式のデータセットが山ほどあります。まずはデータを取得しましょう。

1. SES のコンソールまたは CLI から、Firehose のデリバリーストリームを S3 に対しニアリアルタイムで送信、保存する configuration set を作成します。

NestedJson_1

2. SES を使ってテストメールを送ってみます。送信の際に、作成した configuration set を使用するよう指定します。

SES コンソールから指定を行う場合、More options を選択してください。Configuration Set を含む、いくつかのフィールドが表示されます。

NestedJson_2

また SES の検証手順や AWS CLI を使って、メールボックスシミュレータのアドレスにメッセージを送信できます。

$ aws ses send-email --to bounce@simulator.amazonses.com --from youraddress@example.com --subject "Bounced Like a Bad Check" --text "This should bounce" --configuration-set-name Firehose

3. ログが蓄積される S3 バケットを指定します。

NestedJson_3

ウォークスルー: Athena でクエリ

Amazon Athena は、Amazon S3 に置かれたデータに対し標準 SQL を使って簡単に分析を行える、インタラクティブなクエリサービスです。Athena を使うためにはサーバを用意する必要はなく、したがってインフラを管理する必要もありません。実行したクエリに対してのみ、料金が発生します。CSV,、JSON、ORC、そして Parquet といったさまざまな標準的なデータフォーマットに対応しています。

Hive メタストアと互換性のある DDL ステートメントを用いて、データスキーマを定義することによって、Athena がデータを処理できるようになります。Athena は分散 SQL エンジンの Presto を使用して、クエリを実行します。また Apache Hive の DDL シンタックスによってテーブルやパーティションの作成、削除、変更を行います。Athena は schema-on-read と呼ばれるアプローチを採用しており、それによりクエリを実行するタイミングで初めてスキーマを付与することになります。クエリの結果を得るために、ログに含まれる各フィールドを、対応するカラムにマッピングすることになります。

もし Apache Hive にすでに慣れている場合には、Athena でのテーブル作成は非常に似たやり方で行えます。クエリエディター、ウィザード、JDBCドライバーのいずれかを使って DDL ステートメントを記述することで、テーブルを作成できます。テーブル作成の中で大事なのは SerDe (“Serializer and Deserializer” の略称) です。データフォーマットが JSON のため、Athena でもともとサポートされている org.openx.data.jsonserde.JsonSerDe を使って、データのパースを行います。その際には、Hive/Presto と JSON データセットにまつわる2つのよくある問題に対処しなければなりません。

  • 入れ子または複数階層の JSON
  • (マッピングの制御に使われる) 禁止文字

Athena のクエリエディタでは、最初の Athena テーブルを作る際には次のような DDL ステートメントを使います。LOCATION にはログが置かれている S3 のファイルパスを指定します。

CREATE EXTERNAL TABLE sesblog (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

この DDL ステートメントでは、Presto のデータ型に合わせて JSON データセット内のフィールドを宣言しています。またオブジェクトのグループを扱うために、配列や構造体に似た、Hive のコレクション型を使用しています。

ウォークスルー: 入れ子の JSON

JSON が 3段階で入れ子になっていることにより、mail キーの定義はとてもややこしい形になります。この例では、他のさまざまなキーが入れ子になって内部に含まれた mail という構造体を、一番上の階層で作成します。mail には messageId や destination が2つめの階層として含まれます。timestamp フィールドは、バッククォート (`) 文字に囲まれています。timestamp は Presto のデータ型として予約語になっているため、テーブル作成において混乱が生じないように、予約語と同一名のカラムを定義する際にはバックォートで囲む必要があります。3番目の階層はヘッダデータになります。ここには 名前:値 のペアが複数含まれます。<name:string, value:string> の形をしたオブジェクトの配列として、スキーマの定義ができます。なお予約語のカラムを作成するためには、commonHeaders struct の中にある `from` のようにバックスラッシュで囲む必要があります。

これでテーブルが作成され、クエリを投げることができるようになりました!

SELECT * FROM sesblog limit 10;

この出力結果では、eventTypemail という2つの最上位階層のカラムが表示されていますが、これだとクエリした結果のデータが取得できた、以上の有益な結果は得られません。分析したいデータを取得するために、入れ子表記を使用したクエリを使うことができます。

“月曜日のキャンペーンで、宛先不明で戻ってきたメッセージはどれか?”

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID,
       mail.timestamp as Timestamp
FROM sesblog
WHERE eventType = 'Bounce' and mail.timestamp like '2017-01-09%'

“あるドメインで、宛先不明で戻ってきたメッセージは何件か?”

SELECT COUNT(*) as Bounces 
FROM sesblog
WHERE eventType = 'Bounce' and mail.destination like '%amazonses.com%'

“amazonses.com ドメインに戻ってきたメッセージはどれか?”

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID 
FROM sesblog
WHERE eventType = 'Bounce' and mail.destination like '%amazonses.com%'

データセットからユースケースに応じた結果を得るために、さらに突っ込んだクエリを書くこともできます。作成したテーブルでは、JSON イベント内の tags セクションについてはスキーマを指定していません。続いてはこれをみていきます。

ウォークスルー: マッピングにおける禁止文字の取り扱い

データセットに対する DDL を最初に書く際に、真っ先にぶつかる問題として、ログフォーマットを変更するのが困難であるということと、Hive ではデータ型を定義する際にコロン (:) が大きな役割を果たしているということが挙げられます。イベント内の tag セクションについて、各フィールドをパースするために、JSONSerDe を使う必要があります。このデータによって誰がメッセージを作成したのかがわかるため、監査やセキュリティのユースケースにおいて非常に大事なものです。

Athena のクエリエディタで、以下の DDL を実行して 2 つめの Athena テーブルを作成しましょう。LOCATION として、ログが置かれている S3 バケットを指定します:

CREATE EXTERNAL TABLE sesblog2 (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,ses_source_ip:string,ses_from_domain:string,ses_caller_identity:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

新しいテーブルを作成する際に、SERDEPROPERTIES の記述を書き加えます。これにより、SerDe に追加のパラメタを与えることができます。カラム名の真ん中に : を含んでいるデータを取り扱うための、マッピングのプロパティを記述します。これにより、ses:configuration-setses というカラム名に configuration-set というデータ型が指定されたものとして解釈されます。先ほどの記述と違い、この場合はバッククォートで囲むことはできません。JSON SERDEPROPERTIES のマッピングセクションでは、テーブル作成の際にあらゆる不正な文字を再マッピングしてしまいます。

例えば、ses データ内の ses:configuration-set に対して、先ほどの定義をすることで、Athena に対して ses_configurationset の形でクエリを投げることができます。このマッピングは、S3 嬢のデータに対しては一切変更を加えません。これは Hive の概念としてのみ取り扱われ、既存のデータを置き換えるものではありません。プロパティ内で 4 つのフィールドをマッピングして(コロンを含んだものをすべて、サポートされているアンダースコアに置き換えています)、tag の構造体を作成する際に、この新しいマッピングされた名前を使います。

これで、そのほかの認証・監査に関するカラムにアクセスできるようになったので、クエリを投げることでさらなる疑問を解決できます。

“すべての宛先不明なメッセージを作成したのは誰か?”

SELECT eventtype as Event,
         mail.timestamp as Timestamp,
         mail.tags.ses_source_ip as SourceIP,
         mail.tags.ses_caller_identity as AuthenticatedBy,
         mail.commonHeaders."from" as FromAddress,
         mail.commonHeaders.to as ToAddress
FROM sesblog2
WHERE eventtype = 'Bounce'

特筆すべき点として、mail.commonHeaders.”from” の取り扱いがあります。from は Presto の予約語なので、予約語と解釈させないためにダブルクォーテーション (“) で囲む必要があります。

ウォークスルー: SES カスタムタギングに対するクエリ

SES では AWS の外に対するメッセージに対して、カスタムタグをセットすることができるため、この mail.tag は非常に重要な意味を持ちます。大事なメッセージに tag を付与しておき、その tag を用いて Athena で分析することができます。例えばマーケティングキャンペーンを補足するためにキャンペーンタグを使いたい場合、SES CLI から -tags オプションを使ってタグを付与することができます:

$ aws ses send-email --to success@simulator.amazonses.com --from youraddress@example.com --subject "Perfume Campaign Test" --text "Buy our Smells" --configuration-set-name Firehose --tags Name=Campaign,Value=Perfume

この結果には、カスタムタグが付与されたエントリーが含まれます。

…
		"tags": {
			"ses:configuration-set": ["Firehose"],
			"Campaign": ["Perfume"],
			"ses:source-ip": ["54.55.55.55"],
			"ses:from-domain": ["amazon.com"],
			"ses:caller-identity": ["root"],
			"ses:outgoing-ip": ["54.240.27.11"]
		}
…

キャンペーンタグを管理するための 3 つめのテーブルを作成します。

CREATE EXTERNAL TABLE sesblog3 (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:string,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,Campaign:string,ses_source_ip:string,ses_from_domain:string,ses_caller_identity:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

そして各メールに付与したカスタムタグを使ってクエリを実行することができます。

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID,
       mail.tags.Campaign as Campaign
FROM sesblog3
where mail.tags.Campaign like '%Perfume%'

NestedJson_4

ウォークスルー: プログラムによって hive-json-schema を使った DDL を作成

これらの全ての例では、SES のインタラクションタイプとして send のみをもとにして、テーブル作成を行っています。SES には他にも、delivery、complaint、bounce などのインタラクションタイプがあり、それぞれ複数の追加フィールドを持っています。これらに対応するために、すべての異なる SES eventTypes をパースし、1 つのテーブルとしてクエリできるようなマスター DDL を作成します。

適切に動作する JSONSerDe DDL を作業で記述するのは、退屈な上に間違いを起こしやすいので、ここでは AWS サポートでよく用いられている、オープンソースのツールを使用します。これを使った場合、コロンを含む SES カラムのマッピングのみ記述するだけになります。

このサンプル JSON ファイルには、すべての SES イベントタイプで取りうる全てのフィールドが含まれています。hive-json-schema を使うことで,入れ子になった JSON DDL を記述することができます。

こちらが全てのタイプの SES ログにクエリできる “マスター” DDL です:

CREATE EXTERNAL TABLE sesmaster (
  eventType string,
  complaint struct<arrivaldate:string, 
                   complainedrecipients:array<struct<emailaddress:string>>,
                   complaintfeedbacktype:string, 
                   feedbackid:string, 
                   `timestamp`:string, 
                   useragent:string>,
  bounce struct<bouncedrecipients:array<struct<action:string, diagnosticcode:string, emailaddress:string, status:string>>,
                bouncesubtype:string, 
                bouncetype:string, 
                feedbackid:string,
                reportingmta:string, 
                `timestamp`:string>,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,ses_source_ip:string,ses_outgoing_ip:string,ses_from_domain:string,ses_caller_identity:string>
              >,
  send string,
  delivery struct<processingtimemillis:int,
                  recipients:array<string>, 
                  reportingmta:string, 
                  smtpresponse:string, 
                  `timestamp`:string>
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity",
  "mapping.ses_outgoing_ip"="ses:outgoing-ip"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/'

結論

この投稿では、AWS サービスのログで使われている JSON 形式のデータに対して、Amazon Athena のクエリを投げる実際的なユースケースを紹介しました。ユースケースの中には、宛先不明や迷惑メールフラグを集計するようなものがありました。その他にも、キャンペーンの効果検証のレポーティングのようなものもあります。さらに、どのインスタンスやユーザーがメールを送信したかといった、監査やセキュリティに関するものもありました。さらに入れ子の JSON を扱う方法や SerDe のマッピングについて触れることで、データを加工整形することなく元のフォーマットのままでクエリを投げることができました。

AWS QuickSight のような新しい ツールを使うことで、こうしたデータからダッシュボードを作成することができます。これによりデータのレポーティングがさらに簡単になります。Athena を QuickSight のデータソースとして使う方法は、こちらのブログ記事を参照してください。

さらに、クエリのパフォーマンスを向上させるための最適化を行ったり、、必要なデータだけをスキャンすることでスキャンデータ量を削減するためにパーティションを設定したり、といった改善を実施することができます。限られた時間内にレポートを出す必要があるときには、S3 のライフサイクル設定を使用して、古くなったデータを Amaazon Glacier に移動させたり、削除したりといった対応を取ることもできます。

原文: Create Tables in Amazon Athena from Nested JSON and Mappings Using JSONSerDe(翻訳: SA 志村)

(速報) 2016年AWS Partner Network(APN) Award発表!

みなさん、こんにちは。Partner SA 酒徳です。

本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。
APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記5つの分野において受賞パートナー様が選出されました。

APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。

– APN Partner of the Year 2016
年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞

– APN Rising Star of the Year 2016
APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞

– APN Cloud Business of the Year 2016
AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞

– APN Architecture of the Year 2016
AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞

– APN Reference of the Year 2016
お客様公開事例において、AWSが企業ビジネスに大きく貢献する事を示し、市場に大きな影響を与えたAPNパートナー様が受賞

それでは、早速受賞パートナー様をご紹介させて頂きます。

– APN Partner of the Year 2016
受賞パートナー:アイレット株式会社

 

logo_cloudpack500

 

受賞理由:昨年に引き続き、多くのAWS関連ソリューション、多数の顧客事例のリリースや 積極的なメディア活動を通じて、メディア、エンターテイメント、スタートアップ企業のみならず、企業や教育機関(大学)のAll‐in移行を手掛けるなど更なるAWSビジネスの拡大に貢献されました。 新サービスも積極的に採用して成功させる一方で、エンタープライズ案件も推進してきた結果、著しい売り上げ伸び率を示されました。

 

– APN Rising Star of the Year 2016
受賞パートナー:日本事務器株式会社
logo-NJC-M-01c
受賞理由:自社製の中堅企業/団体向け各種業務パッケージをAWS上で構築されました。日本中にAWSユーザーを拡大いただいただけではなく、自社のワークスタイル革新の一環としてAmazon WorkSpacesを導入。自社がモデルケースとなり、その知見をお客様に届けることを推進いただきました。結果として、この1年の売り上げ伸び率が新規パートナーの首位を記録されました。

 

– APN Cloud Business of the Year 2016
受賞パートナー:株式会社ソラコム

 

soracom

 

受賞理由:IoT通信プラットフォーム「SORACOM」を、AWSの機能をフル活用してAWS上にソフトウェアで構築し、IoT/M2Mに最適化された通信プラットフォームを日本発でグローバルに展開されています。AWS KinesisなどAWSの各種サービスとの親和性も高く、AWS IoTコンピテンシーの認定も受けられました。既に多くのユーザーがIoTの様々なシーンで活用する中で機能の追加、拡張を続けていらっしゃいます。

 

– APN Architecture of the Year 2016
受賞パートナー:株式会社野村総合研究所

 

logo_NRI

 

受賞理由:高速処理、高可用性、高セキュリティを求められる金融業界の証券トレードシステム領域に対して、AWS Lambda を始めとするAWSのマネージドサービスを活用したクラウドネイティブアーキテクチャを構築されました。またお客様の長期的なクラウドジャーニーを策定した上で、本プロジェクトをその第一歩として定義し、レガシーシステムからクラウドらしいアプリケーションへの移行と、クラウドネイティブの圧倒的な開発スピードと効率性を実証した点を高く評価させていただきました。

 

– APN Reference of the Year 2016
受賞パートナー:株式会社オージス総研
OGISRI
受賞理由:AWSを活用した国内最大規模の優れたIoTの成功例として、大阪ガス様のエネファーム事例を公開いただきました。さらに、AWSの各種イベント等でのご登壇のみならず各種メディアでの露出も多く、AWSビジネスに大きく貢献いただきました。ユーザー、事業者の双方に多大なメリットを提供しながら、全国への普及を含め国の燃料電池発電に関する目標達成をサポートする社会的公益性の高い事例でもあります。

 

受賞パートナーの皆様、本当におめでとうございます!
昨年は多くのパートナー様のお力沿いを得られ、AWS Japanとして飛躍の年となりました。今年も昨年以上にエコシステムの拡大、充実をテーマに更なるSuper Powerの原動力にAWSをご活用頂けますと幸いです。
2017年も引き続き、ご支援のほど宜しくお願い申し上げます。

pic_award

 

AWS Alliance一同

3月のAWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー3月の配信についてご案内させて頂きます。今月は2月にリリースされたばかりの「Amazon Chime」をはじめとして、初登場となるサービスが多数あります!

201703_BB

3月の開催予定

サービスカット
3/1(水) 18:00-19:00 Amazon Athena
3/8(水) 18:00-19:00 Amazon Chime
3/15(水) 18:00-19:00 Auto Scaling
3/22(水) 18:00-19:00 Developer Tools (CodeX シリーズ)
3/29(水) 18:00-19:00 Amazon AI

ソリューションカット
3/14(火) 12:00-13:00 Well-Architected Framework
3/28(火) 12:00-13:00 動画配信 on AWS

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。

このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。

ソリューションの概要
このブログ記事のソリューションでは、

1. IAMロールの作成

2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

3. アタッチされているIAMロールの付け替え

この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。
ここでは、AWSコマンドラインインターフェイス(CLI)の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。

IAMロールの作成

注:既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。

AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。

AWS CLIからIAMロールを作成

1. AWS CLIから、create-roleコマンドを呼び出し、信頼ポリシー YourNewRole-Trust-Policy.jsonに基づいきYourNewRoleというIAMロールを作成します。


$aws iam create-role --role-name YourNewRole --assume-role–policy-document file://YourNewRole-Trust-Policy.json

このIAMロールにアカウントのリソースへのアクセス権を付与するに、attach-role-policyコマンドを呼び出します。 この例では、アカウント内のすべてのAmazon S3バケットとバケット内のオブジェクトへの読み取り専用アクセスがアプリケーションに必要であると想定しています。 そのため、AWS管理ポリシーである、AmazonS3ReadOnlyAccess を使用することにします。 AWS管理ポリシーの詳細については、「管理ポリシーの使用」を参照してください。


$aws iam attach-role-policy --role-name YourNewRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3. create-instance-profileコマンドを呼び出し、続いてadd-role-to-instance-profileコマンドを実行し、IAMインスタンスプロファイル”YourNewRole-Instance-Profile“を作成します。 インスタンスプロファイルにより、EC2はIAMロール”YourNewRole“をEC2インスタンスに渡すことができます。 詳細については、「インスタンスプロファイルの使用」を参照してください。


$aws iam create-instance-profile --instance-profile-name YourNewRole-Instance-Profile

$aws iam add-role-to-instance-profile --role-name YourNewRole --instance-profile-name YourNewRole-Instance-Profile

YourNewRole“というIAMロールが正常に作成されました。

IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

これで、YourNewRoleというIAMロールをEC2インスタンスYourInstanceIdにアタッチする準備が整いました。 ロールを添付するには:

associate-iam-instance-profileコマンドを呼び出して、新しく作成されたIAMロールの”YourNewRole-Instance-Profile“、”YourNewRole“のインスタンスプロファイルをEC2インスタンス”YourInstanceId“にアタッチします。


$aws ec2 associate-iam-instance-profile --instance-id YourInstanceId --iam-instance-profile Name=YourNewRole-Instance-Profile

2. describe-iam-instance-profile-associationコマンドを呼び出すことで、IAMロールがインスタンスにアタッチされていることを確認します。


$aws ec2 describe-iam-instance-profile-associations

3. これで、IAMロールを使用してAWSリソースにアクセスできるようになるため、インスタンスから長期間保管した鍵を削除するようにアプリケーションを更新できます。

アタッチされたIAMロールの付け替え

役割の要件が変更され、IAMロールを介してEC2インスタンスに付与された権限を変更する必要がある場合は、IAMロールに関連付けられたポリシーを置き換えることもできます。 ただし、このIAMロールを使用する他のEC2インスタンスのアクセス許可も変更されます。

代わりに、replace-iam-instance-profile-associationを呼び出して、現在アタッチされているIAMロール”YourNewRole“を別のIAMロールに置き換えることができます。 次の例では、”YourCurrentAssociation-id“を使用して現在のiam-instance-profile-associationインスタンスを示し、”YourReplacementRole-Instance-Profile“を使用して、そのインスタンスに関連付ける置換インスタンスプロファイルを示します 。 これらのプレースホルダーを、適切なassociation-idとアカウントのIAMインスタンスプロファイル名に置き換えてください。


$aws ec2 replace-iam-instance-profile-association --association-id YourCurrentAssociation-id --iam-instance-profile Name=YourReplacementRole-Instance-Profile

注:YourCurrentAssociation-idは、describe-iam-instance-profile-associationsを呼び出すことで取得できます。

最後に

このブログ記事で紹介しました通り、インスタンスを再起動することなく、既存のEC2インスタンスにIAMロールをアタッチすることで、アプリケーションがAWSによって提供される一時的なセキュリティ資格情報を使用できるようにすることができます。 ミッションクリティカルなワークロードを終了することなく、EC2インスタンスにアタッチされたIAMロールを置き換えることもできます。

この投稿に関するコメントがある場合は、下記の「コメント」セクションに投稿してください。 ご質問やご提案がありましたら、IAMフォーラムでコメント下さい。

– Apurv

翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

AWS IPv6 の更新 – 15 のリージョンおよび複数の AWS のサービスにまたがるグローバルサポート

過去数年間に、IPv6 のサポートを AWS の多くの異なる部分に追加してきました。最初は Elastic Load BalancingAWS IoTAWS Direct ConnectAmazon Route 53Amazon CloudFrontAWS WAF、および S3 Transfer Acceleration から開始し、最終的には先月発表した Virtual Private Cloud の EC2 インスタンスに対する IPv6 のサポート (当初は US East (Ohio) リージョンで利用開始) にまで拡大されました。本日は、VPC の EC2 インスタンスに対する IPv6 のサポートが、合計 15 のリージョンで利用でき、これらのリージョンのうち 9 つで、IPv6 に対する Application Load Balancer のサポートが利用できるようになったことをお知らせします。IPv6 アドレスを使用できるアプリケーションを構築およびデプロイして、サーバー、オブジェクトストレージ、ロードバランサー、およびコンテンツ配信サービスと通信できます。Apple および他のベンダーからの IPv6 サポートの最新のガイドラインに従い、モバイルアプリケーションは、AWS と通信するときに IPv6 アドレスを使用できるようになりました。

IPv6 が 15 リージョンで利用可能に
新しい VPC および既存の VPC の EC2 インスタンスに対する IPv6 のサポートが、US East (Northern Virginia)US East (Ohio)US West (Northern California)US West (Oregon)South America (Brazil)Canada (Central)Europe (Ireland)Europe (Frankfurt)Europe (London)Asia Pacific (Tokyo)Asia Pacific (Singapore)Asia Pacific (Seoul)Asia Pacific (Sydney)Asia Pacific (Mumbai)、および AWS GovCloud (US) リージョンで利用可能になり、今すぐ使用を開始できます。新しい VPC を作成するときに、AWS Management Console から IPv6 を有効にできます。

Application Load Balancer
US East (Northern Virginia)US West (Northern California)US West (Oregon)South America (Brazil)Europe (Ireland)Asia Pacific (Tokyo)Asia Pacific (Singapore)Asia Pacific (Sydney)、および AWS GovCloud (US) リージョンの Application Load Balancer は、デュアルスタックモードで IPv6 をサポートし、IPv4 または IPv6 経由でアクセス可能になりました (その他のリージョンのサポートは数週間以内に追加する予定です)。ALB を設定するときに dualstack オプションを有効にし、セキュリティグループで要件に応じて IPv6 トラフィックを許可または拒否するようにします。dualstack オプションの選択方法は次のとおりです。

このオプションを有効にするには、 set-ip-address-type コマンドを実行するか、 SetIpAddressType 関数を呼び出します。この新機能の詳細については、ロードバランサーのアドレスタイプに関するドキュメントをご覧ください。

IPv6 のまとめ
VPC の EC2 インスタンスに対する IPv6 のサポート開始までに行われた IPv6 のリリースは、CloudFront、WAF、および S3 Transfer Acceleration です。このリリースにより、個別の CloudFront ディストリビューションに対して IPv6 のサポートを有効にできます。新しく作成したディストリビューションはデフォルトで IPv6 をサポートし、既存のディストリビューションはわずかなクリック操作でアップグレードできます (Route 53 エイリアスレコードを使用している場合、ドメインに AAAA レコードを追加する必要もあります)。IPv6 のサポートを有効にすると、新しいアドレスが CloudFront アクセスログに表示されます。また、このリリースにより、AWS WAF を使用して、IPv4 または IPv6 アドレス経由で到着するリクエストを検査し、S3 Transfer Acceleration 用の新しいデュアルスタックエンドポイントを使用できます。Route 53 – このリリースでは、IPv6 経由の DNS クエリのサポートが追加されました (必要な AAAA レコードのサポートは既に提供されています)。それ以降のリリースで IPv6 エンドポイントのヘルスチェックのサポートが追加され、エンドポイントの状態をモニタリングし、DNS フェイルオーバーを準備できます。IoT – この製品のリリースには、デバイスと AWS IoT 間のメッセージ交換に対する IPv6 のサポートが含まれます。S3 – このリリースでは、デュアルスタックのエンドポイント経由で S3 バケットへのアクセスのサポートが追加されました。Elastic Load Balancing – このリリースにより、Elastic Load Balancer 用のパブリック環境でルーティング可能な IPv6 アドレスが追加されました。Direct Connect – パブリックおよびプライベート VIF (仮想インターフェイス) で single および dualstack 設定をサポートします。

Jeff;

毎日集計される料金表の通知 ~ AWS料金表API

昨年、AWS のお客様とパートナーから、AWS のサービスの料金を取得するためのシステム的な方法を求める要望が寄せられました。このニーズに対して、昨年 12 月に 13 の AWS のサービスの料金を対象とした AWS の料金表 API を発表しました。この API は、ダウンロード用に JSON および CSV 形式で料金表データを提供し、お客様は AWS のサービスの料金を問い合わせることができます。料金表 API では、Amazon SNS 通知を通じて料金変更の更新情報を受け取ることもできます。

AWS 料金表の API の拡張
過去 3 か月に、当社は AWS の料金表 API サービスを拡張し、すべての AWS のサービスについて料金表データを提供するようにしました。クラウドベースのソリューションの構築またはクラウドへのオンプレミスワークロードの移行に関するコスト分析を行っているお客様は、AWS のサービスの包括的な料金表にこれまでよりも簡単にアクセスできます。これにより、お客様とパートナーは、クラウドソリューションの予算、予測、および計画をより詳細に管理できます。AWS の料金表 API の拡張に加えて、お客様はサインアップして割引料金、新しいサービスやインスタンスタイプの通知を受け取ることができます。通知の受信のサブスクライブの際は、更新情報を受け取るタイミングをカスタマイズでき、1 日 1 回、または料金の更新が発生するたびに設定できます。1 日 1 回の通知を選択した場合、SNS 通知にはその日に適用されたすべての料金変更が含まれます。料金表 API にサブスクライブした場合に受け取る E メール通知のサンプルを次に示します。

料金表 API の使い方を簡単に見てみましょう。最初に、料金表 API を介して料金情報にアクセスし、オファーインデックスファイルとオファーファイルという 2 種類のファイルをダウンロードします。オファーインデックスファイルは JSON ファイルとして利用でき、サポートされている AWS のサービスと、関連するサービスオファーファイルの URL が記載されています。このオファーファイルでは、単一の AWS のサービスに関する製品や料金が一覧表示され、CSV または JSON ファイル形式として利用できます。両方とも単純なダウンロードリンクを介してアクセスでき、簡単な方法で料金表データファイルを入手できます。

今すぐ料金表 API の使用を開始し、いずれの AWS のサービスについても、料金表データを入手できます。AWS の料金表 API の拡張によりすべての AWS のサービスが対象になったことで、料金表 API へのサブスクライブにより、最新の AWS の割引料金の情報を受け取るとともに、新しいサービスの紹介を受けることができます。

AWS の料金表 API の詳細、および API 通知へのサブスクライブ方法の詳細については、サービスについて紹介している前の AWS ブログ投稿、および AWS の料金表 API の使用に関するドキュメントを参照してください。

– Tara

事前にご確認ください – AWSにおける2016年12月31日(日本時間2017年1月1日)のうるう秒

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください!

次回のうるう秒(通算27回目)が、UTC(世界標準時)の2016年12月31日 23:59:60として挿入されます(訳注:日本標準時では2017年1月1日 8:59:60になります)。これは地球上での時刻(協定世界時)と太陽時(天文時)とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。

前回のうるう秒の際に出した情報(事前にご確認ください – AWSでのうるう秒対応)は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります:

AWS調整時刻(AWS Adjusted Time) –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します(UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで)。AWS調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。)

Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。

Amazon RDS – 大多数のAmazon RDS インスタンスは (UTCで設定されている場合)“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。

サポートが必要ですか?
このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。

Jeff;

翻訳:下佐粉 昭(@simosako

原文:https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

新しい AWS Application Discovery Service コンソール

AWS Application Discovery Service は、クラウドへの移行計画を立てるのに役立ちます。 AWS クラウド導入フレームワークの中心的なコンポーネントとして、これはシステムに関する重要な情報を検出して収集する処理を自動化するプロセスを簡略化します (詳細については、新しい AWS Application Discovery Service – クラウド移行を計画するをお読みください)。 データ収集には 2 つのオプションがあります。軽量エージェントを物理サーバーまたは VM にインストールすることもできますし、VMware 環境で Agentless Discovery Connnector を実行することもできます。 どちらの場合でも、AWS Application Discovery Service は以下の情報を収集します。

  • インストール済みのアプリケーションおよびパッケージ。
  • 実行中のアプリケーションおよびプロセス。
  • TCP v4 および v6 接続。
  • カーネルブランドおよびバージョン。
  • カーネル設定。
  • カーネルモジュール。
  • CPU およびメモリの使用状況。
  • プロセスの作成および終了イベント。
  • ディスクおよびネットワークイベント。
  • NIC 情報。
  • DNS、DHCP、および Active Directory の使用。

軽量エージェントは、リッスンする TCP ポートと関連するプロセスに関する情報も収集します。この機能は Agentless Discovery Connector にも近日中に追加される予定です。 情報は収集され、オプションのレビューのためにローカルに保存されてから、ポート 443 の安全な接続を介してクラウドにアップロードされます。この情報は処理され、相関され、暗号化された形式でリポジトリに格納されます。その後、その情報を使用して移行したいアプリケーションを選択することができます。 新しい Application Discovery Service コンソールこのサービスについて最初に書いた際、処理され相関された情報は、分析ツールや移行ツールで使用するために XML 形式と CSV 形式で利用できました。 本日、AWS はクラウド移行プロセス全体を簡略化するよう設計された、新しい Application Discovery Service コンソールをリリースしました。エージェントをインストールし、アプリケーションを検出し、アプリケーションの依存関係をマッピングし、アプリケーションのパフォーマンスを測定するのに役立ちます。では、見ていきましょう。 ランディングページには、利点と機能のリストがあり、このサービスの概要をつかめます。

その後、データ収集のオプションを選びます (サーバーまたは VM でのエージェント、または VMware 環境でのエージェントレス)。 [Learn more] をクリックしてセットアップ手順の詳細を見ることができます。

すぐに使用できるエージェントとコネクタ (両方を一緒に使うことができます) のセットアップにより、[Start data collection] をクリックして、選択したエージェント/コネクタから検出を開始することができます。

サーバーは検出されたとおりに表示されます。

数回クリックするだけで、1 つまたは複数のサーバーを選択して、それらを指定したアプリケーションにグループ化することができます。

各サーバーに 1 つ以上のタグを追加できます。

ネットワーク接続、プロセス、ネットワークトラフィックを生成または消費するプロセスなど、各サーバーの詳細情報をすべて表示できます。

および

アプリケーションの一覧を表示できます (それぞれ 1 つ以上のサーバーで実行されています)。

各アプリケーションの詳細についても説明されています。

これらの情報があれば、AWS クラウドへの移行を計画して実行する準備が整います。詳細については、Application Discovery Service ユーザーガイドをお読みください。

Jeff;

PS – Application Discovery Service パートナーは、お客様のクラウド移行をぜひお手伝いしたいと思っています。