Category: Management Tools*


コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか?については多様なやり方が考えられますが、今日はAWS CloudFormationを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にAmazon ECSAWS LambdaといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはAWS Command Line Interface (CLI)やSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。

デプロイツールとしてのCloudFormationのメリット

最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。

  • デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能
  • 宣言的にデプロイが定義・実行できる
  • アプリケーションに関連する他のAWSリソースも合わせて管理可能

現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。

デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能

例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。

CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。

もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。

宣言的にデプロイが定義・実行できる

AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。

CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。

アプリケーションに関連する他のAWSリソースも合わせて管理可能

ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、AWS Identity and Access Management (IAM)のRoleは良く使われますし、データベースとしてAmazon DynamoDBを使ったり、ECSのコンテナへの負荷分散にElastic Load Balancingを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。

CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。

CloudFormationを使ったECSのデプロイ例

こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。

ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、AWS CodePipelineがデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。

参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。

https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml

Resources:
  ECSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument: |
        {
            "Statement": [{
                "Effect": "Allow",
                "Principal": { "Service": [ "ecs.amazonaws.com" ]},
                "Action": [ "sts:AssumeRole" ]
            }]
        }
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole

  Service:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref Cluster
      Role: !Ref ECSServiceRole
      DesiredCount: !Ref DesiredCount
      TaskDefinition: !Ref TaskDefinition
      LoadBalancers:
        - ContainerName: simple-app
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Sub ${AWS::StackName}-simple-app
      ContainerDefinitions:
        - Name: simple-app
          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}
          EntryPoint:
            - /usr/sbin/apache2
            - -D
            - FOREGROUND
          Essential: true
          Memory: 128
          MountPoints:
            - SourceVolume: my-vol
              ContainerPath: /var/www/my-vol
          PortMappings:
            - ContainerPort: 80
          Environment:
            - Name: Tag
              Value: !Ref Tag
        - Name: busybox
          Image: busybox
          EntryPoint:
            - sh
            - -c
          Essential: false
          Memory: 128
          VolumesFrom:
            - SourceContainer: simple-app
          Command:
            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"
      Volumes:
        - Name: my-vol

CloudFormationを使ったLambdaのデプロイ例

Lambdaの構成管理およびデプロイには、AWS Serverless Application Model (SAM)を使うことができます。これはCloudFormationの拡張表記であり、例えば以下のようなテンプレートを書くと簡単にAmazon API GatewayとLambda Functionをデプロイ(初回は構築含む)をすることができます。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Outputs the time
Resources:
  TimeFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      CodeUri: ./
      Events:
        MyTimeApi:
          Type: Api
          Properties:
            Path: /TimeResource
            Method: GET

Lambdaのデプロイを行う際、多くのケースでは依存ライブラリ等もまとめたzipファイルを作成し、Amazon Simple Storage Service (S3)にアップロードした上でFunctionを更新することになります。AWS SAMを使っているとこれをAWS CLIを使って簡単に実現できます。実装例は以下のドキュメントに詳しく紹介されています。

まとめ

この投稿では、AWS CloudFormationをコンテナやサーバレスアプリケーションをデプロイするためのツールとしてご紹介しました。多くの実際のユースケースで利用可能なものですのでご参考にして頂ければ幸いです。サーバレスアプリのデリバリパイプラインまで含めた実装を実際にご覧になりたい場合には、AWS CodeStarで作成されるプロジェクトも参考になるかと思いますので合わせてご参考頂ければと思います。

新機能 – Amazon CloudWatch ダッシュボードでの API と CloudFormation のサポート

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。

新しい API および CLI
コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、AWS CloudFormation のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。

ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。

GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。

PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。

DeleteDashboards / aws cloudwatch delete-dashboards – 1 つ以上のダッシュボードを削除します。

ダッシュボードの概念
これらの関数とコマンドの使用方法を説明したいと思います。詳細な説明に移る前に、ダッシュボードの重要な概念と属性のいくつかを示します。

グローバル – ダッシュボードは AWS アカウントの一部であり、特定の AWS リージョンとは関連付けられていません。各アカウントは最大 500 個のダッシュボードを持つことができます。名前が付けられる – 各ダッシュボードには、AWS アカウント内で一意の名前があります。名前の長さは最大 255 文字です。グリッドモデル – 各ダッシュボードはセルのグリッドで構成されます。グリッドは全体で 24 個のセルで、必要なだけ高くすることができます。ダッシュボードの各ウィジェットはグリッド座標の特定のセットに配置され、整数値の数のグリッドセルにまたがるサイズです。ウィジェット (視覚化) – 各ウィジェットは、テキストまたは CloudWatch メトリクスのセットを表示できます。テキストは Markdown を使って指定し、1 つの値、折れ線グラフ、または積み上げ棒グラフとして表示できます。各ダッシュボードは最大 100 個のウィジェットを持つことができます。メトリクスを表示するウィジェットは、CloudWatch アラームと関連付けることもできます。ダッシュボードには、コンソール内から表示および編集できる JSON 表現があります。[Actions] メニューをクリックして、[View/edit source] を選択します。

ダッシュボードのソースは以下のとおりです。

この JSON は、実際のアプリケーションを構築する際の参考にしてください。ご覧のとおり、ダッシュボードの各ウィジェットに対して widgets 配列にエントリがあります。各エントリは、タイプ、位置、サイズで始まる 1 つのウィジェットを示します。

API を使用したダッシュボードの作成
特定のリージョンの各 EC2 インスタンスに対するウィジェットがあるダッシュボードを作成するとします。Python および AWS SDK for Python を使用して、次のように開始します (私のコードの未熟さはご容赦ください)。

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

次にインスタンスを反復処理し、それぞれに対して widget ディクショナリを作成し、それを widgets 配列に追加します。

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

位置 (xy) をループ内で更新し、グリッドを作成します (位置を指定しない場合、ウィジェットは左から右へ、上から下へレイアウトされます)。

        x += width
        if (x + width > max_width):
            x = 0
            y += height

すべてのインスタンスを処理した後で、ウィジェット配列の JSON バージョンを作成します。

body   = {'widgets' : widgets}
body_j = json.dumps(body)

そして、ダッシュボードを作成または更新します。

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

コードを実行すると、次のダッシュボードが作成されます。

CloudWatch チームは、プログラムで作成されるダッシュボードにはテキストウィジェットを含め、ダッシュボードが自動生成されたことと、その操作を実行したソースコードまたは CloudFormation テンプレートへのリンクを含めることを推奨しています。つまり、ダッシュボードに対して手動の帯域外チェンジャーを実行しないことを推奨しています。前述したように、各メトリクスウィジェットは CloudWatch アラームと関連付けることもできます。アラームは、プログラムで作成するか、サンプル CPU 使用率アラーム などの CloudFormation テンプレートを使用して作成できます。これを行うように決定した場合、アラームのしきい値がウィジェットに表示されます。この詳細については、Tara Walker の最近の投稿「Amazon CloudWatch Launches Alarms on Dashboards」を参照してください。さらに一歩先に進んで、CloudWatch イベントと Lambda 関数を使って特定のリソースの作成と削除を追跡し、変更に合わせてダッシュボードを更新することができます。この方法については、「Keeping CloudWatch Dashboards up to Date Using AWS Lambda」を参照してください。

CLI を使用したダッシュボードへのアクセス
コマンドラインからダッシュボードにアクセスして操作することもできます。たとえば、シンプルなリストを生成できます。

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

そして、Disk-Metrics ダッシュボードを削除できます。

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

ダッシュボードを定義する JSON を取得することもできます。

 

CloudFormation を使用したダッシュボードの作成
ダッシュボードは、CloudFormation テンプレートで指定することもできます。YAML 形式のシンプルなテンプレートを示します ( DashboardBody が依然として JSON で指定されています)。

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

テンプレートをファイルに配置し、コンソールまたは CLI を使用してスタックを作成します。

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

ダッシュボードを次に示します。

ご利用可能
この機能は今すぐ利用できます。本日から使い始めることもできます。ダッシュボードあたり最大 50 メトリクスを持つ 3 つのダッシュボードを無料で作成できます。追加のダッシュボードの料金は、CloudWatch 料金表ページに示すように、1 か月あたり 3 USD です。毎月新しい API 関数に対して最大 100 万回の呼び出しを無料で実行できます。それを超えた場合の料金は、1,000 回の呼び出しごとに 0.01 USD です。

Jeff;

ランサムウェア「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

 

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

 

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

 

AWSサービスの効果的な使い方

 

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

 

AWSコンソール上でのAmazon Inspector 結果詳細画面例

 

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

 

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

 

推奨するAWSソリューション

 

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山 隼人, セキュリティソリューションアーキテクト
坪 和樹, クラウドサポートエンジニア
長谷川 淳, クラウドサポートエンジニア

Amazon CloudWatch LogsとMonologを使用したPHPアプリケーションログ

ロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。今回の例では、PHPアプリケーションからのログを、Amazon CloudWatch Logsに出力させます。これを実現するために、すでに普及しよく利用されている標準に準拠した既存のソリューションを使いたいと思っていました。これらの理由からオープンソースのログライブラリであるPHP Monolog(https://github.com/Seldaek/monolog)を使用します。

PHP Monolog

新しいPHPアプリケーション、フレームワーク、またはサービスを扱う人にとって、ソリューション間で頻繁に現れる技術の選択肢の1つとしてアプリケーションログ用のMonologを利用することが挙げられます。PHP Monologは標準に準拠したPHPライブラリで、開発者はデータベース、ファイル、ソケット、さまざまなサービスなどのさまざまな種類のフォーマットにログを送信できます。PHP MonologはPSR-3で定義されたPHPロギングの標準化よりも前に、PSR-3のインターフェースと標準を実装していました。これにより、Monologはロギングライブラリ用の共通インタフェースに準拠しています。CloudWatch LogsでMonologを使用すると、PSR-3互換ロギングソリューションが作成されます。Monologは、Laravel、Symfony、CakePHPなど多くの異なるアプリケーションやフレームワークで使用できます。今日の例は、アプリケーションログの目的で、PHP Monologを使用してCloudWatchLogsに情報を送信し、CloudWatchのアラームと通知でアプリケーションデータを使用できる構造とプロセスを構築することです。これにより、アプリケーションからのログをキーにAmazon EC2 AutoScalingのようなサービスのアクションに使用することができます。

Amazon CloudWatch Logs

顧客第一主義の組織として、AWSはお客様やAWSパートナーが要望する重要な機能やサービスを絶えず構築し、リリースしています。本日、ハイライトされるサービスの1つがAmazon CloudWatch Logsです。CloudWatch Logsを使用すると、アプリケーション、オペレーティングシステムおよびインスタンス、AWSサービス、およびその他のさまざまなソースからのログファイルの情報を保存できます。以前のブログ記事では、CloudWatch Logsをさまざまなプログラミング例とともに紹介しました。

ブログ記事にはCloudWatch Logsを使用してアプリケーションからのエントリを保存するPHPの例があります。この例を使用してスタンドアロンソリューションとして拡張し、アプリケーション内からCloudWatch Logsにログを送ることができます。この例では、PHP Monologを活用してこの機能を強化します。

Monologの実装

Monologを使用開始するには、Composer(https://getcomposer.org/)を使用して必要なライブラリをインストールします。以下の手順では、AWS SDK for PHP、PHP Monologおよび CloudWatch Logsへのログを有効にするMonologのアドオンをインストールします。

curl -sS https://getcomposer.org/installer | php 
php composer.phar require aws/aws-sdk-php 
php composer.phar require monolog/monolog 
php composer.phar require maxbanton/cwh:^1.0

あるいは、次のエントリをcomposer.jsonファイルにコピーし、php composer.phar installコマンドでインストールすることもできます。

{
    "minimum-stability": "stable",
    "require": {
        "aws/aws-sdk-php": "^3.24",
        "aws/aws-php-sns-message-validator": "^1.1",
        "monolog/monolog": "^1.21",
        "maxbanton/cwh": "^1.0"
    }
}
Local logging

PHP Monologが利用できるようになったので、それを実装しテストすることができます。まず、1ファイルにロギングする例を示します。

require "vendor/autoload.php";

use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;

$logFile = "testapp_local.log";

$logger = new Logger('TestApp01');
$formatter = new LineFormatter(null, null, false, true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);
$logger->pushHandler($infoHandler);
$logger->info('Initial test of application logging.');

前の例では、先ほどインストールしたコンポーザーライブラリが必要です。新しいロガーラインは「TestApp01」として、チャンネル名を設定します。次の行は、未使用のログ項目の括弧を削除する新しいLineFormatterを作成します。次の行は、識別されるファイル名として先を確立しtestapp_local.log、およびINFOログレベルでそれを関連付けます。次に、ストリームハンドラにフォーマットを適用します。次に、更新された形式のストリームハンドラをハンドラリストに追加します。最後に、INFOというログレベルで新しいメッセージが記録されます。ログレベルとハンドラの詳細については、Monolog GitHubページIETF RFC 5424およびPSR-3を参照してください。

機能を確認するために、ログファイルの内容を表示できるようになりました:

Syslog logging

シンプルなログエントリをローカルファイルに書き込むことができたので、次の例ではシステムのSyslogを使用してイベントを記録しています。

$logger = new Logger($appName);

$localFormatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);

$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($localFormatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);

$logger->info('Test of PHP application logging.');
$logger->warn('Test of the warning system logging.');

syslogメッセージのフォーマットが$syslogFormatterという値で変更されていることがわかります。syslogは各ログエントリに日付/時刻を挿入するので、これらの値をログテキストに含める必要はありません。syslog機能はlocal0に設定され、すべてのWARNINGメッセージはsyslogにともに送信され、INFOレベルのメッセージとWARNINGレベルのメッセージはローカルファイルに記録されます。Syslog機能とログレベルに関する追加情報は、Syslog Wikipediaのページを参照してください。

Logging to CloudWatch Logs

Monologの基本的な使い方を見てきたので、いくつかのログをCloudWatch Logsに送りましょう。Monologライブラリ用のAmazon Web Services CloudWatch Logs Handlerを使用して、MonologをCloudWatch Logsに統合することができます。この例では、認証アプリケーションによってログ情報が生成されます。

use Aws\CloudWatchLogs\CloudWatchLogsClient;
use Maxbanton\Cwh\Handler\CloudWatch;
use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SyslogHandler;

$logFile = "testapp_local.log";
$appName = "TestApp01";
$facility = "local0";

// Get instance ID:
$url = "http://169.254.169.254/latest/meta-data/instance-id";
$instanceId = file_get_contents($url);

$cwClient = new CloudWatchLogsClient($awsCredentials);
// Log group name, will be created if none
$cwGroupName = 'php-app-logs';
// Log stream name, will be created if none
$cwStreamNameInstance = $instanceId;
// Instance ID as log stream name
$cwStreamNameApp = "TestAuthenticationApp";
// Days to keep logs, 14 by default
$cwRetentionDays = 90;

$cwHandlerInstanceNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);
$cwHandlerInstanceError = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::ERROR);
$cwHandlerAppNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);

$logger = new Logger('PHP Logging');

$formatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$cwHandlerInstanceNotice->setFormatter($formatter);
$cwHandlerInstanceError->setFormatter($formatter);
$cwHandlerAppNotice->setFormatter($formatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);
$logger->pushHandler($cwHandlerInstanceNotice);
$logger->pushHandler($cwHandlerInstanceError);
$logger->pushHandler($cwHandlerAppNotice);

$logger->info('Initial test of application logging.');
$logger->warn('Test of the warning system logging.');
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-success' ]);
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-failure' ]);
$logger->error('Application ERROR: System Error');

 

この例では、アプリケーション認証イベントはPHP配列として渡され、JSONとしてCloudWatch Logsに表示されます。login-successおよびlogin-failureの結果を伴うイベントは、インスタンスIDに関連付けられたログストリームと、アプリケーション名に関連付けられたログストリームの両方に送信されます。

 

これらの異なるストリームの場所を使用して、インスタンスごとまたはアプリケーションごとにメトリックとアラームを作成できます。過去5分間にアプリケーションにログインしたユーザーの総数に対するメトリックを作成するとします。イベント・グループを選択し、メトリック・フィルターの作成を選択します。

次のページでは、フィルタとテストを同じウィンドウで作成できます。フィルタデータについては、ログエントリのJSON文字列を使用します。すべての正常なログインを抽出するには、次の文字列を入力します。

{ $.result = login-success }

下記のように、フィルタの詳細が表示されます。フィルタ名を識別しやすい値に変更しました。メトリック名前空間にはアプリケーション名に関連付けられた値があり、メトリック名にはログイン成功数が反映されます。

CloudWatch Logsを介して受け取ったこの情報に基づいて、アラームを作成して通知を送信したり、(Amazon EC2スケーリングの決定などの)アクションとることができます。

これらの値を使用すると、5分以内に50回以上ログインが成功するたびに警告が表示されます。

Laravel logging

Monologは、一般的なLaravel PHPフレームワークを含む多くのPHPアプリケーションとフレームワークのロギングソリューションとして使用されています。この例では、Laravel内でMonolog with CloudWatch Logsの使用を示します。最初のステップは、Laravelアプリケーションの現在のログ設定を調べることです。アプリケーションルート内でconfig/app.phpを開くと、さまざまなログ設定が表示されます。デフォルトでは、Laravelはデバッグのベースラインログレベルを使用して単一のログファイルにログするように設定されています。

次に、ここからの説明と例を使用して、Laravel内のサービスプロバイダとしてAWS SDK for PHPを追加します。

また、CloudWatchログのMonologライブラリをcomposer.jsonファイルに追加して、アプリケーションに含めることもできます(図を参照)。

これで、現在のLaravel Monolog構成をカスタム構成で拡張する必要があります。この手順の詳細は、Laravel Error and Loggingページを参照してください。以下は、bootstrap/app.phpファイルへの追加例です。

use Maxbanton\Cwh\Handler\CloudWatch;

$app->configureMonologUsing( function($monolog) {

    $cwClient = App::make('aws')->createClient('CloudWatchLogs');
    $cwGroupName = env('AWS_CWL_GROUP', 'laravel-app-logs');
    $cwStreamNameApp = env('AWS_CWL_APP', 'laravel-app-name');
    $cwTagName = env('AWS_CWL_TAG_NAME', 'application');
    $cwTagValue = env('AWS_CWL_TAG_VALUE', 'laravel-testapp01');
    $cwRetentionDays = 90;
    $cwHandlerApp = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ $cwTagName => $cwTagValue ] );

    $monolog->pushHandler($cwHandlerApp);
});

テスト目的のために、routes/web.phpのテストルートにロギングコールを追加します。

Route::get('/test', function () {
    Log::warning('Clicking on test link!!!');
    return view('test');
});

テストルートが呼び出されると、ログはCloudWatch Logsに表示されるようになりました。

結論

この例では、PHP Monologを使用してローカルファイル、syslogおよびCloudWatch Logsにログを書き込む方法を紹介しました。また、一般的なPHPアプリケーションフレームワーク内で、MonologとCloudWatch Logsの統合を実施しました。最後に、CloudWatch Logsメトリックフィルタを作成し、CloudWatch Alarmsに適用して、ログからのデータを通知とともにスケーラビリティの決定とともに実行可能にする方法をご紹介しました。CloudWatch Logsは、PHPアプリケーションの集中的にロギング機能を提供し、Monologと組み合わせることで、確立されたプロジェクトやカスタムエンゲージメント内で使用するライブラリの可用性を保証します。
(翻訳はSA 森が担当しました。原文はこちら)

New – AWS マネジメントツールのブログ

過去数年で AWS ブログのコレクションが拡大しました。右側のリストをご覧になれば分かるように、現在では実に幅広い様々なトピックや開発ツールに関するブログをご提供しています。また英語以外の言語でも、AWS ブログをご覧いただくことができます。コレクションに最近追加されたブログは AWS Management Tools Blog です。このブログでは AWS ツールを取り上げ、ユーザーがプロビジョン、設定、モニタリング、トラックのサポートや AWS のコスト管理、大規模なオンプレミスリソースの管理について説明しています。今後ブログで紹介予定のトピックには、機能の更新に関する技術的な詳細情報、ヒントやトリック、サンプルアプリ、CloudFormation テンプレート、ユースケースのディスカッションなども含まれています。ブログ開始当初の投稿をいくつか以下にご紹介します。

こうした便利な内容をお届けするコンテンツを毎回見逃さないようにするには、ブログの RSS フィードへの登録をご検討ください。

Jeff;

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。

このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。

ソリューションの概要
次の図は、この記事のソリューションの概要を示しています。

ソリューションの仕組みは次のとおりです。

1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。
2. CloudWatch Logs グループはにアラートがイベントとして送信されます。
3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。
4. Amazon ESにはログに記録されたアラートデータがロードされます。
5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。

デプロイ時の考慮事項

この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。

デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。

Cloud Formation テンプレートは選択したリージョンで、下記の流れで展開されます。

1. CloudWatch LogsにアクセスするためのAWS Identity and Access Management(IAM)ロールが作成され、Amazon Linuxを実行する2つのEC2インスタンスにアタッチされます。注:サンプルHIDSアラートデータを提供するために、2つのEC2インスタンスが自動的に構成され、シミュレートされたHIDSアラートをローカルに生成します。
2. OSSEC、CloudWatch Logsエージェント、およびテスト環境で使用される追加パッケージをインストールして設定します。
3. ターゲットのHIDS Amazon ESドメインを作成します。
4. ターゲットのHIDS CloudWatch Logsグループを作成します。
5. Amazon ESにHIDSアラートを送信するために、Lambda関数とCloudWatch Logsサブスクリプションを作成します。

CloudFormationスタックがデプロイされた後、Amazon ESドメインのKibanaインスタンスにアクセスして、テスト環境のセットアップの最終ステップを完了することができます。これについては後で説明します。

このブログの投稿の範囲外にはなりますが、既存のEC2環境にOSSECを導入する場合は、監視対象のログファイル、完全性チェック用のディレクトリ、アクティブな応答など、必要な構成を決定する必要があります。通常、環境の最適化のためにシステムのテストとチューニングに時間を要すことがほとんどです。 OSSECのドキュメントは、このプロセスに慣れ始めるのに適しています。エージェントのインストールと別のOSSECマネージャを使用してイベントを一元的に処理してからCloudWatch Logsにエクスポートするという、OSSECの展開には別のアプローチをとることもできます。この展開では、エージェントとマネージャの間に追加のサーバーコンポーネントとネットワーク通信が必要です。 Windows ServerはOSSECでサポートされていますが、エージェントベースのインストールが必要なため、OSSECマネージャが必要です。 OSSECのアーキテクチャと展開オプションの詳細については、「OSSECアーキテクチャ」を参照してください。

ソリューションのデプロイ
手順の概要は次のとおりです。

1. CloudFormationスタックを起動します。
2. Kibanaのインデックスパターンを設定し、アラートの探索を開始します。
3. Kibana HIDSダッシュボードを設定し、アラートを視覚化します。

1. CloudFormationスタックの起動

CloudFormationテンプレートを使用して、プロビジョニングプロセスを自動化しテスト環境を起動します。次の入力パラメータでは、展開のためにターゲットVPCとサブネット(インターネットアクセスが必要)を識別する必要があります。ターゲットサブネットがインターネットゲートウェイを使用する場合は、AssignPublicIPパラメーターをtrueに設定します。ターゲットサブネットがNATゲートウェイを使用する場合は、AssignPublicIPのデフォルト設定をfalseのままにしておきます。

まず、デプロイしたリージョンにあるS3バケットにLambda Function 展開パッケージを配置する必要があります。これを行うには、圧縮された展開パッケージをダウンロードし、同じリージョンバケットにアップロードします。 S3へのオブジェクトのアップロードの詳細については、「Amazon S3へのオブジェクトのアップロード」を参照してください。

また、スタックの作成後に環境にアクセスするための信頼できる送信元IPアドレスまたはCIDRブロックと、インスタンスに関連付けるEC2キーペアを提供する必要があります。 EC2キーペアの作成については、「Amazon EC2を使用したキーペアの作成」を参照してください。また、信頼できるIPアドレスまたはCIDRブロックは、Kibanaアクセス用にAmazon ESアクセスポリシーの自動作成のために使用されます。すべてのIPv4アドレスがインスタンスにアクセスできるようにする0.0.0.0/0を使用するのではなく、特定のIPアドレスまたはCIDR範囲を使用することをお勧めします。インスタンスへのインバウンドトラフィックの認可の詳細については、「Linuxインスタンスのインバウンドトラフィックの認可」を参照してください。

入力パラメータを確認したら(詳細は次のスクリーンショットと表を参照)、CloudFormationスタックを作成します。

Input parameter インプット パラメータの説明
1. HIDSInstanceSize テストサーバーのEC2インスタンスサイズ
2. ESInstanceSize Amazon ESインスタンスのサイズ
3. MyKeyPair デプロイ後にインスタンスに安全に接続できる公開鍵/秘密鍵のペア
4. MyS3Bucket ZIP展開パッケージを使用したS3バケット
5. MyS3Key ZIP展開パッケージ用の領域内のS3キー
6. VPCId ソリューションを展開するAmazon VPC
7. SubnetId 選択したVPC内のアウトバウンド接続を持つサブネットID(インターネットアクセスが必要)
8. AssignPublicIP サブネットがインターネットゲートウェイ経由で接続するように設定されている場合はtrueに設定します。サブネットがNATゲートウェイ経由で接続するように設定されている場合はfalseに設定されます
9. MyTrustedNetwork EC2インスタンスおよびAmazon ESエンドポイントへのアクセスをホワイトリストに登録するために使用される信頼できるソースIPまたはCIDRブロック

CloudFormationスタックの作成を継続するには:

1. 入力パラメータを入力して、次へを選択します。
2. 「オプション」ページで、デフォルトを受け入れて「次へ」を選択します。
3. レビューページで詳細を確認し、AWS CloudFormationがIAMリソースを作成する可能性があることを確認します。チェックボックスをオンにし、作成を選択します。 (スタックは約10分で作成されます)。

スタックを作成したら、CloudFormation OutputsタブのHIDSESKibanaURLをメモしてください。そして次のKibanaの設定手順に進みます。

2.Kibanaのインデックスパターンを設定し、アラートの調査を開始
このセクションでは、Kibanaの初期セットアップを実行します。 Kibanaにアクセスするには、CloudFormationスタック出力(前のセクションを参照)でHIDSESKibanaURLを見つけて選択します。これにより、Amazon ESインスタンスに自動的にプロビジョニングされるKibanaインスタンスが表示されます。 CloudFormation入力パラメータで指定したソースIPを使用して、Amazon ESアクセスポリシーが自動的に設定されます。次のようなエラーが表示された場合は、Amazon ESのアクセスポリシーが正しいことを確認する必要があります。

{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: hids-alerts"}

Amazon ESドメインへのアクセスを保護する方法の詳細については、「Amazon Elasticsearchサービスドメインへのアクセスを制御する方法」を参照してください。

OSSEC HIDSアラートは現在Amazon ESに処理されています。 Kibanaを使用してアラートデータをインタラクティブに分析するには、Amazon ESで分析するデータを識別するインデックスパターンを設定する必要があります。索引パターンに関する追加情報は、Kibanaのドキュメントを参照してください。
インデックス名またはパターン ボックスに「cwl-2017.*」と入力します。インデックスパターンは、ラムダ関数内でcwl-YYYY.MM.DDとして生成されるため、月と日のワイルドカード文字を使用して2017のデータと一致させることができます。Time-field nameドロップダウンリストから@timestamp を選択し作成します。


Kibanaでは、ディスカバーペインを選択して、作成されているアラートを表示できるようになりました。リアルタイムに近いアラートの表示のリフレッシュレートを設定するには、右上の時間範囲(Last 15 minutesなど)を選択します。

自動更新を選択し、5秒などの間隔を選択します。

Kibanaでは、設定した時間枠内で5秒間隔で自動更新するように設定する必要があります。次のスクリーンショットに示すように、アラートがカウントグラフとともに更新されるはずです。

EC2インスタンスはCloudFormationによって自動的に設定され、アクティビティをシミュレートして次のようないくつかのタイプのアラートを表示します。

  • 成功したsudoからROOT実行 :Linuxのsudoコマンドが正常に実行されました。
  • Webサーバー400のエラー・コード : サーバーは、クライアント エラー(形式が不適切な要求構文、サイズが大きすぎる、無効なリクエスト・メッセージ・フレーミング、不正なリクエスト・ルーティングなど)によりリクエストを処理できません。
  • SSHのセキュアでない接続試行(スキャン) : SSHリスナーへの無効な接続試行。
  • ログインセッションが開かれました : システムでログインセッションが開かれました。
  • ログインセッションが閉じられました : システムのログインセッションが閉じられました。
  • 新しいYumパッケージがインストールされています : パッケージがシステムにインストールされています。
  • Yumパッケージが削除されました : パッケージがシステムから削除されました。

次のスクリーンショットに示すように、いくつかのアラートフィールドを詳しく見ていきましょう。

上記番号付きアラートフィールド(スクリーンショット)は、次のように定義されています

1. @log_group – ソースとなるCloudWatch Logグループ
2. @log_stream – CloudWatchログのストリーム名(InstanceID)
3. @message – ソースalerts.jsonからのJSONペイロードOSSECログ
4. @owner – アラートが発生したAWSアカウントID
5. @timestamp – Lambda関数によって適用されるタイムスタンプ
6. full_log – ソースファイルからのログイベント
7. location – ソースログファイルのパスとファイル名
8. rule.comment – 一致したOSSECルールの簡単な説明
9. rule.level – 0から16までのOSSECルール分類(詳細は、ルール分類を参照)
10. rule.sidid – 一致したOSSECルールのルールID
11. srcip – アラートをトリガした送信元IPアドレス。この場合、シミュレートされたアラートにはサーバのローカルIPが含まれています

また、Kibanaクエリーバーに検索条件を入力して、HIDSアラートデータをインタラクティブに調べることができます。たとえば、次のクエリを実行すると、ソースIPが10.10.10.10であるEC2 InstanceID i-0e427a8594852eca2のすべてのrule.level 6アラートを表示できます。

“rule.level: 6 AND @log_stream: "i-0e427a8594852eca2" AND srcip: 10.10.10.10”

シンプルテキスト、Luceneクエリ構文、またはJSONベースのElasticsearch Query DSLを使用して検索を実行できます。データの検索に関する追加情報は、Elasticsearchのドキュメントを参照してください。

3. Kibana HIDSダッシュボードの設定、アラートを視覚化

アラートの傾向とパターンを時間の経過とともに分析するには、グラフとグラフを使用してアラートデータを表現すると便利です。私はKibanaインスタンスにインポートできる基本ダッシュボードテンプレートを設定しました。

KibanaインスタンスにサンプルのHIDSダッシュボードのテンプレートを追加するには:

1. テンプレートを ローカルに保存し、Kibanaナビゲーションペインで[管理]を選択します。
2. 保存オブジェクト、インポート、およびHIDSダッシュボードテンプレートを選択します。
3. HIDSアラートダッシュボードエントリの右側にある目のアイコンを選択します。インポートされたダッシュボードに移動します。

Kibanaダッシュボードテンプレートをインポートして選択すると、次のスクリーンショットに示すように、HIDSダッシュボードが表示されます。このサンプルHIDSダッシュボードには、アラートの時間、アラートの種類、ルールレベルの内訳、上位10のルールソースID、および上位10のソースIPが含まれています。

アラートデータを詳細に調べるには、次の2つのスクリーンショットに示すように、フィルタするアラートタイプを選択します。

ソースIPアドレスや時間範囲などの基準に基づいてアラートの詳細を表示できます。 Kibanaを使用してアラートデータを視覚化する方法の詳細については、「Kibanaユーザーガイド」を参照してください。

まとめ

このブログ記事では、CloudWatch Logs を使用してOSSEC HIDSからほぼリアルタイムでアラートを収集し、CloudWatch Logsサブスクリプションを使用して、Kibanaとの分析と可視化のためにアラートをAmazon ESに渡す方法を示しました。このソリューションによってデプロイされたダッシュボードは、AWS環境における防御の深いセキュリティ戦略の一環として、EC2のセキュリティ監視を改善するのに役立ちます。

このソリューションを使用して、EC2への攻撃、異常な活動、およびエラーの傾向を検出することができます。また、システムの修復作業の優先順位付けや、VPCセキュリティグループルールVPCネットワークACLAWS WAFルールなど、追加のセキュリティコントロールを導入する場所を決定するのに役立ちます。

この投稿に関するコメントがある場合は、下の「コメント」セクションに追加してください。このソリューションの実装に関する問題や問題がある場合は、CloudWatchまたはAmazon ESフォーラムで新しいスレッドでお知らせ下さい。このソリューションのソースコードはGitHubで入手できます。 OSSEC固有のサポートが必要な場合は、「OSSECサポートオプション」を参照してください。

– Cameron (翻訳はSA酒徳が担当しました。原文はこちら:How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances)

Amazon CloudWatch がダッシュボードにアラームを追加

Amazon CloudWatch は、AWS のリソースに関するメトリックス、ログ、イベントをリアルタイムで提供および収集することで、アマゾン ウェブ サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。CloudWatch では、リソースのレイテンシー、エラー発生率、CPU 使用率などの主要メトリックスが自動的に測定されます。さらにお客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。昨年 11 月、Amazon CloudWatch に新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。CloudWatch に追加されたダッシュボードのアラームにより、お客様は AWS で実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。

CloudWatch のダッシュボードは、複数のリージョンにまたがる AWS リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。CloudWatch のダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。アラームの状態が変わると、Auto Scaling ポリシーなどのアクションが実行されます。または、Amazon SNS に通知が送信されます。ダッシュボードにアラームを追加するという新たな方法により、CloudWatch のユーザーは、複数のリージョンにまたがって AWS のリソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。さらに、ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。アラームには次の 3 つの状態があります。

  • OK: アラームのメトリックス値はしきい値に達していない
  • INSUFFICIENT DATA: データ不足。最初にトリガされたアラームのメトリックス値は、データ不足のため、[OK] 状態か [ALARM] 状態か判定できない
  • ALARM: アラームのメトリックス値はしきい値に達している

ダッシュボードでは、[ALARM] 状態は赤、[INSUFFICIENT DATA] 状態はグレイ、[OK] 状態は無色で表示されます。ダッシュボードのアラームは、Line、Number、Stacked area の各ウィジェットで表示できます。

  • Number ウィジェット: 目的のメトリックスの最新の値をすばやく効率的に確認できます。最新のメトリックスデータに応じてアラームの状態が変わるたびに背景色が変わります。
  • Line ウィジェット: 選択したメトリックスのコレクションの実値を線グラフで表示します。ダッシュボードにアラームのしきい値と状態が水平線で示されます。この水平線を境に、しきい値に達しているかどうかが一目でわかります。
  • Stacked area ウィジェット: 選択したメトリックスのコレクションについて正味の合計結果をグラフで表示します。Stacked area ウィジェットは、メトリックスの上に別のメトリックスをロードして、メトリックスの分布と貢献度を示します。オプションとして、メトリックスの貢献度をパーセントで表示することもできます。アラームのしきい値と状態も水平線で表示されます。

現在、アラームに関連する複数のメトリックスを同じウィジェットに追加する作業が進行中です。この機能はお客様からのフィードバックに基づいて進化しています。

ダッシュボードにアラームを追加する CloudWatch
ダッシュボードでアラームを使用する方法を簡単に確認しましょう。AWS コンソールで、CloudWatch サービスに移動します。CloudWatch コンソールで、[Dashboards] を選択します。[Create dashboard] ボタンをクリックして CloudWatchBlog ダッシュボードを作成します。

CloudWatchBlog ダッシュボードを作成すると、このダッシュボードにウィジェットを追加するためのダイアログボックスが表示されます。ここでは、ウィジェットを追加する手順をスキップして、ダッシュボードにアラームを追加する手順に進むことにします。したがって、[Cancel] ボタンをクリックして、CloudWatch コンソールの [Alarms] セクションに進みます。

CloudWatch コンソールの [Alarms] セクションでは、現在のリージョンのすべてのアラームとその状態が一覧表示されます。

既に述べたように、アラームには 3 種類の状態があります。上に示したコンソールには、アラームごとに状態が表示されています。必要に応じて、コンソールのフィルタを使って状態の種類別にアラームを表示することもできます。たとえば、状態が [ALARM] のアラームだけを確認するとします。この場合は、現在のリージョンで状態が [ALARM] のアラームをフィルタで絞り込みます。

これで、現在の状態が [ALARM] になっている 2 つのアラームだけが表示されます。1 つは、Amazon DynamoDB テーブルのプロビジョニングされた書き込みキャパシティーユニットをモニタリングするためのものであり、別の 1 つは、アクティブな Amazon Elasticsearch インスタンスの CPU 使用率をモニタリングするためのものです。

CloudWatchBlog ダッシュボードをトラブルシューティング手段として利用し、Elasticsearch ソリューションとそのインスタンスの問題を特定して診断するシナリオを検討してみましょう。まず、Amazon Elasticsearch の CPU 使用率のアラームとして [ES Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームを追加するには、目的のアラーム (この例では [ES Alarm]) の横にあるチェックボックスを選択します。次に、アラームを選択した状態で、[Add to Dashboard] ボタンをクリックします。

表示された [Add to dashboard] ダイアログボックスで、CloudWatchBlog ダッシュボードを選択できます。ここで、アラームを表示するウィジェットの種類を選択することもできます。ES Alarm を Line ウィジェットで表示することにし、[Add to dashboard] ボタンをクリックして、このアラームをダッシュボードに追加します。

[ES Alarm] が [CloudWatchBlog] ダッシュボードに正常に追加されると、確認メッセージが CloudWatch コンソールに表示されます。

コンソールの [Dashboards] セクションに移動して [CloudWatchBlog] ダッシュボードを選択すると、[ES Alarm] アラームの Line ウィジェットがダッシュボードに表示されます。[ES Alarm] ウィジェットをダッシュボードの一部として保存するには、[Save dashboard] ボタンをクリックして、このウィジェットのダッシュボードへの追加を確定します。

既に説明したように、CloudWatch ダッシュボードを使用する利点の 1 つは、さまざまなリージョンからの複数のアラームをダッシュボードに追加できることです。この例では、ダッシュボードを Elasticsearch ソリューションのトラブルシューティング手段として利用しているので、このソリューションに関連するいくつかのアラームとメトリックスを [CloudWatchBlog] ダッシュボードに表示することにします。そのため、Elasticsearch インスタンス用に別のアラームを作成してダッシュボードに追加します。まず、コンソールの [Alarms] セクションに戻り、[Create Alarm] ボタンをクリックします。

[Create Alarm] ダイアログボックスが開いて、このリージョンで現在利用可能なすべてのメトリックスが表示されます。メトリックスの要約で、Elasticsearch のために 21 のメトリックスが追跡中であることを簡単に確認できます。[ES Metrics] リンクをクリックして、アラームの作成に使用できる各メトリックスを表示します。

Elasticsearch インスタンスのために表示された個別のメトリックスの中から、新しいアラームを関連付けるメトリックスを選択します。[WriteLatency] メトリックスを使うことにして、このメトリックスの横にあるチェックボックスを選択して [Next] ボタンをクリックします。

次の画面で、アラームの詳細として、名前、説明、アラームのしきい値、時間、アラームのアクションを入力します。新しいアラームの名前を ES Latency Alarm とし、他の残りのフィールドにも入力します。[Create Alarm] ボタンをクリックして、新しいアラームの作成を終了します。

アラームの追加が正常に終了すると、Alarms コンソールの上部に確認メッセージボックスが表示され、新しく作成したアラームの状態がアラームリストに表示されます。

次に、[ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームの横にあるチェックボックスを選択して [Add to Dashboard] ボタンをクリックします。

[Add to Dashboard] ダイアログボックスが開いたら、今回は [Stacked area] ウィジェットを選択します。このウィジェットを使用して [ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに表示します。[Add to Dashboard] ボタンをクリックして、[ES Latency Alarm] ウィジェットをダッシュボードに追加します。

コンソールに戻ると、ウィジェットが正常に追加されたことを確認するメッセージが表示されます。[Dashboards] セクションで [CloudWatchBlog] ダッシュボードをクリックすると、ダッシュボードに 2 つのウィジェットが表示されます。このウィジェットをダッシュボードに保存するには、[Save dashboard] ボタンをクリックします。

最後に、CloudWatch の新しい機能であるダッシュボードのアラームでは、他のリージョンのアラームやメトリックスをダッシュボードに追加して全体をトラブルシューティングの対象にすることができます。アラームウィジェットを使ってダッシュボードにメトリックスを追加してみましょう。コンソール内で、現在のリージョンである米国東部 (オハイオ) から、米国東部 (バージニア北部) リージョンに移動します。

CloudWatch コンソールの [Metrics] セクションに進みます。このセクションに、米国東部 (バージニア北部) リージョンで使用されるサービスのメトリックスが表示されます。

Elasticsearch ソリューションは、Lambda 関数をトリガーして EmployeeInfo DynamoDB データベースの CRUD (作成、読み込み、更新、削除) のすべての変更を DynamoDB ストリーム経由でキャプチャし、それらの変更を Elasticsearch ドメインである taratestdomain 内に書き込みます。したがって、DynamoDB のテーブルメトリックスを追跡するためにメトリックスを [CloudWatchBlog] ダッシュボードに追加します。

そこで、[EmployeeInfo] データベースの [ProvisionedWriteCapacityUnits] メトリックスを [CloudWatchBlog] ダッシュボードに追加します。

[Add to Dashboard] ダイアログで、[CloudWatchBlog] ダッシュボードを選択し、このメトリックスを [Number] ウィジェットで表示することを選択します。

これで、米国東部 (バージニア北部) の [ProvisionedWriteCapacityUnits] メトリックスが [CloudWatchBlog] ダッシュボードに追加され、その Number ウィジェットが米国東部 (オハイオ) のアラームと一緒にダッシュボードに表示されます。この更新をダッシュボードに保存するには、もうおわかりだと思いますが、[Save dashboard] ボタンをクリックします。

 

まとめ
ダッシュボードの開始方法は簡単です。アラームを前もってモニタリングする新たな手段としてリージョンをまたいでダッシュボードのアラームを使用し、トラブルシューティング計画を策定して、目的のメトリックスを確認できます。また、最初にメトリックス UI でメトリックスを選択し、次にメトリックスの視覚化に適したウィジェットの種類に変更することもできます。ダッシュボードのアラームは、Line、Stacked area、Number の各ウィジェットで表示できます。さらに、ダッシュボードでアラームと並んでいる Text ウィジェットを使用して、アラームの状態の変更を処理する方法に関するステップや所見を追加することもできます。

Amazon CloudWatch のウィジェットおよびその他のダッシュボードのウィジェットの詳細については、Amazon CloudWatch ドキュメントおよび CloudWatch の「開始方法」を参照してください。

Tara

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/

AWS クイックスタートの更新 – Tableau、Splunk、Compliance、Alfresco、Symantec

AWS クイックスタートは AWS で人気のソリューションのデプロイをサポートします。各クイックスタートは AWS のソリューションアーキテクトやパートナーが設計し、セキュリティや高可用性における AWS のベストプラクティスを活用しています。テストまたは本番稼働環境ですぐにクイックスタートをご利用いただけます。シングルクリックで起動できるクイックスタートには、広範囲にわたる内容を取り上げたデプロイメントガイドと AWS CloudFormation テンプレートが含まれています。クイックスタートは次の 7 つのカテゴリに分類されています。

  • 開発運用
  • データベースとストレージ
  • ビッグデータと分析
  • セキュリティ & コンプライアンス
  • Microsoft & SAP
  • ネットワークとアクセス
  • その他

過去 2 か月間で 6 つの新しいクイックスタートをコレクションに追加し、合計数は 42 件になりました。次に、新しいクイックスタートの各カテゴリの概要をご紹介します。

Tableau Server (ビッグデータと分析)
AWS クイックスタートの Tableau ServerAWS Cloud で完全に機能する Tableau Server のデプロイをサポートします。デフォルト VPC でシングルノードを起動したり、新規または既存の VPC でマルチノードクラスターのデプロイメントができます。クラスターアーキテクチャについてはこちらをご覧ください: CloudFormation テンプレートは Tableau アクティベーションキーについてもプロンプトを表示します。

Splunk Enterprise (ビッグデータと分析)
AWS クイックスタートの Splunk Enterprise は、AWS クラウドで分散した Splunk Enterprise 環境のデプロイをサポートします。2 つ以上のアベイラビリティーゾーンと既存の VPC で開始したり、新しい VPC を作成することができます。アーキテクチャについてはこちらをご覧ください: テンプレートは S3 バケット名と Splunk ライセンスファイルへのパス (バケット内) のプロンプトを表示します。

UK OFFICIAL (セキュリティ & コンプライアンス)
AWS クイックスタートの UK-OFFICIAL は United Kingdom (UK) OFFICIAL により分類されたワークロードをサポートする、標準化された AWS クラウド環境をセットアップします。この環境は NCSC Cloud Security Principles と CIS Critical Security Controls にある対象サービスのガイドラインに準拠します (詳細はセキュリティコントロールマトリックスをご覧ください)。アーキテクチャについてはこちらをご覧ください:

Alfresco One
AWS クイックスタートの Alfresco One は、AWS クラウドで Alfresco One Enterprise Content Management サーバークラスターのデプロイをサポートします。既存の VPC にデプロイまたはパブリックサブネットやプライベートサブネットで新しい VPC をセットアップできます。アーキテクチャについてはこちらをご覧ください: クラスターを起動するには Alfresco のトライアルライセンスが必要です。

Symantec Protection Engine (セキュリティ & コンプライアンス)
AWS クイックスタートの Symantec Protection Engine は、1 時間以内に Symantec Protection Engine (SPE) をデプロイできるようにサポートします。デプロイが完了すると (新規または既存の VPC にデプロイが完了)、SPE の API を使用してマルウェア検出や脅威検出をアプリケーションに組み入れることができます。さらにプロキシと連携すれば、ウィルスやトロイの木馬またはその他のマルウェアが潜んでいないかトラフィックをスキャンすることもできます。アーキテクチャについてはこちらをご覧ください: クイックスタートを使用するには、SPE ライセンスを購入するか SPE AMI に登録してください。 クイックスタートの詳細についてはクイックスタートのよくある質問をご覧ください。クイックスタートの設計に参加するにはクイックスタート協力者向けガイドをご覧ください。

Jeff;

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。
最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。
データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。
関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。
このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。

  • 異なる3つのデータセットを適合させて索引付けし、検索可能にします。
  • 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。
  • Amazon AthenaAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

(more…)