Management Tools

CloudWatch

Overview

Cloud WatchはAWSのリソースをモニタリングするサービスである。提供される機能は以下のとおりである。

• 以下のようなメトリクスのハイパーバイザレベルでの追跡・収集(EC2の標準メトリクス)
  1. CPU利用率
  2. DisK I/O
  3. ネットワーク転送量
  4. ステータスチェック(死活監視)
• 以下のようなカスタムメトリクス収集
  1. メモリ使用量
  2. ディスク空き容量
  3. ウェブページの読み込み時間
  4. リクエストのエラー発生率
  5. 同時処理・スレッド数
• メトリクスの閾値設定・アラーム通知、アクション実行
  1. (例)CPU使用率が50%を下回るとオートスケーリング、AmazonLamdaのイベント発生
• CloudWatch Logsを使用してアプリケーションログを保存・モニタリング

Note

各サービスによって標準となるメトリクスは異なる。ALBではリクエスト数などをCloudWatchで収集しており、そのメトリクスに応じてEC2のオートスケールイベントを発生することは可能である。

Note

CloudWatchだけでシステム運用の全てのメトリクスの収集は難しいので、必要に応じて運用監視ミドルウェアの導入を行うこと。

CloudWatch EventとSNSを用いたアラートの作成

ここでは、AWSマネジメントコンソールにログインすることをCloudWatch Eventに設定し、イベントを検知したらSNSを使用してメール通知するアラートを設定する。 最初にSNSでEmailを発信するトピックを作成する。必要に応じて、 Overview も参照すること。

Amazon SNSサービスを選択し、「トピック」メニューから「トピックの作成」ボタンを押下する。

トピック名を入力し、「トピックの作成」ボタンを押下する。

トピックを購読するサブスクリプションとしてEmail配信を設定する。「サブスクリプション」メニューから「サブスクリプションの作成」ボタンを押下する。

以下の要領でサブスクリプションの設定を行う。

• トピックARN: 上記で作成したトピックのARN
• プロトコル：Eメール
• エンドポイント：送信対象となるEmail

続いて、CloudWatchEventを作成する。「CloudWatch」サービスで、「イベント」メニューを選択し、「今すぐ始める」ボタンを押下する。

以下の要領で、イベントを設定し、「設定の詳細」ボタンを押下する。

• イベントソース
  • イベントパターン：サービス別のイベントに一致するイベントパターンの構築
  • サービス名：AWSコンソールのサインイン
  • イベントタイプ：サインインイベント
  • 任意のユーザ
• ターゲット
  • SNSトピック：上記で作成したSNSトピック
  • 入力の設定：一致したイベント

ルール名を入力し、「ルールの作成」ボタンを押下する。

一度サインアウトした後に、しばらく時間を置いたのち、ログインすると設定したアドレス宛にメールが送信できるようになる。

CloudWatch EventとLambdaの実行

ここでは、特定のセキュリティグループの変更を監視し、変更があるとLambdaファンクションを使って設定を元に戻すアクションを実行する。 まず、Lambdaファンクションを実行する際に必要となるIAMポリシー及びロールを作成する。「IAM」サービスから、「ポリシー」メニューを選択し、「ポリシーの作成」ボタンを押下する。

「JSON」タブを選択し、以下の通りポリシーを設定する。

{
    "Version": "2012-10-17",
    "Statement": [
         {
             "Effect" : "Allow",
             "Action": "ec2:DescribeSecurityGroups",
             "Resource": "*"
         },
         {
             "Effect" : "Allow",
             "Action": "logs:CreateLogGroup",
             "Resource": "*"
         },
         {
             "Effect" : "Allow",
             "Action": [
                 "Logs:CreateLogStream",
                 "logs:PutLogEvents"
             ],
             "Resource": "*"
         }
     ]
 }

ポリシー名を入力し、「ポリシーの作成」ボタンを押下する。

続いて、「ロール」メニューから「ロールの作成」ボタンを押下する。

「このロールを使用するサービスを選択」として「Lambda」を選択し、「次のステップ：アクセス権限」ボタンを押下する。

上記で作成したポリシーをアタッチし、「次のステップ：タグ」ボタンを押下する。タグは特に設定せず先へ進む。

ロール名を入力し、「ロールの作成」ボタンを押下する。

次に実行するLambdaファンクションを作成する。「AWS Lambda」サービスを選択し、「関数」メニューから「関数の作成」ボタンを押下する。

以下の要領で関数を作成し、「関数の作成」ボタンを押下する。

• 関数名：関数名を入力
• ランタイム：Python2.7
• アクセス権限：前節で作成したIAMロール

関数として、以下のPythonコードを入力する。

# Copyright [2016]-[2016] Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License.
# A copy of the License is located at
#
#     http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file.
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
# either express or implied. See the License for the specific language governing permissions
# and limitations under the License.
#
# Description: Checks that all security groups block access to the specified ports.
#
# awscwevents_lambda_security_group.py
#
# Author: jeffscottlevine
# Date: 2016-09-05
#
# This file contains an AWS Lambda handler which responds to AWS API calls that modify the ingress
# permissions of security groups to see if the permissions now differ from the required permissions

# as specificed in the REQUIRED_PERMISSIONS variable below.
#
# Note: The permissions are not remediated within this function because doing so could possibly
# trigger a recursion issue with this Lambda function triggering itself.
#
# 2017-01-13 - Added "Ipv6Ranges" to REQUIRED_PERMISSIONS to accommodate IPv6 within Amazon VPC.

import boto3
import botocore
import json


APPLICABLE_APIS = ["AuthorizeSecurityGroupIngress", "RevokeSecurityGroupIngress"]

# Specify the required ingress permissions using the same key layout as that provided in the
# describe_security_group API response and authorize_security_group_ingress/egress API calls.

REQUIRED_PERMISSIONS = [
    {
        "IpProtocol" : "tcp",
        "FromPort" : 80,
        "ToPort" : 80,
        "UserIdGroupPairs" : [],
        "IpRanges" : [{"CidrIp" : "0.0.0.0/0"}],
        "PrefixListIds" : [],
        "Ipv6Ranges": []
    },
    {
        "IpProtocol" : "tcp",
        "FromPort" : 443,
        "ToPort" : 443,
        "UserIdGroupPairs" : [],
        "IpRanges" : [{"CidrIp" : "0.0.0.0/0"}],
        "PrefixListIds" : [],
        "Ipv6Ranges": []
    }
]


# evaluate_compliance
#
# This is the main compliance evaluation function.

def evaluate_compliance(event):
    event_name = event["detail"]["eventName"]
    if event_name not in APPLICABLE_APIS:
        print("This rule does not apply for the event ", event_name, ".")
        return

    group_id = event["detail"]["requestParameters"]["groupId"]
    print("group id: ", group_id)

    client = boto3.client("ec2");

    try:
         response = client.describe_security_groups(GroupIds=[group_id])
    except botocore.exceptions.ClientError as e:
         print("describe_security_groups failure on group ", group_id, " .")
         return

    print("security group definition: ", json.dumps(response, indent=2))

    ip_permissions = response["SecurityGroups"][0]["IpPermissions"]
    authorize_permissions = [perm for perm in REQUIRED_PERMISSIONS if perm not in ip_permissions]
    revoke_permissions = [perm for perm in ip_permissions if perm not in REQUIRED_PERMISSIONS]

    if authorize_permissions or revoke_permissions:
        if authorize_permissions:
            for perm in authorize_permissions:
                print("This permission must be authorized: ", json.dumps(perm, separators=(',',':')))
        if revoke_permissions:
            for perm in revoke_permissions:
                print("This permission must be revoked: ", json.dumps(perm, separators=(',',':')))
    else:
        print("All permissions are correct.")

# lambda_handler
#
# This is the main handle for the Lambda function.  AWS Lambda passes the function an event and a context.

def lambda_handler(event, context):
    print("event: ", json.dumps(event))

    evaluation = evaluate_compliance(event)

変更監視対象とするセキュリティグループを作成する。EC2サービスから、セキュリティグループメニューから、「セキュリティグループの作成」を押下する。

特にルールは設定せず作成する。

作成したセキュリティグループを変更監視対象に設定する。CloudWatchサービスから「イベント」メニューを選択し、「今すぐ始める」を押下する。

• イベントパターン：サービス別のイベントに一致するイベントパターンの構築を選択
  • サービス名：CloudTrail
  • イベントタイプ：AWS API Call via CloudTrail
  • 任意のオペレーションを選択

編集リンクを押下し、イベントパターンを以下のように変更する。

{
   "detail-type": [
       "AWS API Call via CloudTrail"
   ],
   "detail": {
       "eventSource": [
           "ec2.amazonaws.com"
       ],
       "eventName": [
           "AuthorizeSecurityGroupIngress",
           "RevokeSecurityGroupIngress"
       ],
       "requestParameters": {
           "groupId": [
              "sg-0d7b9ee604811ba7d"
           ]
       }
   }
}

ターゲットは以下のように設定し、「設定の詳細」を押下する。

• Lambda関数：前節で作成したLambda関数を設定
• SNSトピック：前節で作成したSNSトピック

名前を入力後、「ルールの作成」を押下する。

セキュリティグループを変更すると自動的に変更が通知されるようになる。

CloudTrail

Overview

CloudTrailはアカウントユーザに対する全てのAPIリクエストを記録するサービスである。 セキュリティ分析やAWSリソースの変更の追跡、トラブルシューティングに活用できる。

CloudTrailとCloudWatchLogsの統合

操作履歴をCloudWatchLogsで確認できるようにCloudTrailと統合を行う。「CloudTrail」サービスから「証跡情報」メニューを選択し、「証跡の作成」ボタンを押下する。

以下の要領で証跡情報の作成を行い、「次へ」ボタンを押下する。

• 証跡名：任意の証跡名を入力
• 証跡情報を全てのリージョンに適用：はい
• 管理イベント：全て
• ストレージの場所：新しいバケットを作成する：はい
• S3バケット：新規作成するバケット名を入力
• 新規または既存のロググループ：なければ新しいロググループを作成

デフォルトで用意されているCloudTrailからのCloudWatchLogsへのアクセス権限がついたIAMロールとポリシー名を設定し、「許可」ボタンを押下する。

CloudConfig

CloudConfigはAWSのリソースの設定の履歴、変更通知利用できる。 例えば、セキュリティグループのこれまでの設定履歴や変更タイミングなどをトレースすることができる。 サポートされるリソースの対象は こちら　になる。 各々、以下のような情報の取得が可能である。

• AWS設定のスナップショット
• AWSリソースの設定履歴
• リソース変更通知
• リソースの関連性

請求レポート

Todo

請求レポートについて詳述。

Trusted Advisor

AWS Trusted Advisorでは、パフォーマンスとセキュリティに関する最も一般的な4つの推奨事項をチェックする。

• コストの最適化
• セキュリティ
• 耐障害性
• パフォーマンス向上

Todo

Trusted Advisorについて記述。

AWS Systems Manager

Overview

AWS Systems Managerは、EC2をはじめとしたサーバリソースの大規模な運用・管理を効率化・自動化するサービスである。 EC2インスタンスへのパッチ適用やインベントリ(システム構成)情報の収集、OSのアップデートやドライバの更新の実行、AMIの管理などを、リソース単位でまとめ大規模に実行することが可能である。 また、複数のリソースで共有可能なパラメータストアの作成やブラウザベースでのEC2インスタンスへのアクセスなどシステム管理に関わる複数の機能群で構成される。Systems Managerの主な特徴・機能は以下の通りである。

Systems Managerの主な特徴・機能

機能	概要
Remote Connect	通常必ず行うセキュリティインバウンド設定やSSHキーなしで、ブラウザやAWS CLIを使ってEC2インスタンスへアクセスする機能
Resource Group	AWSの複数のリソースをグルーピング化できる機能
Insight & Dashboard	リソースごとに収集したソフトウェアインベントリ情報(OSバージョンなどの構成管理情報)やCloudTrail、Trusted Advisorなどのインサイト情報をダッシュボードで俯瞰的に参照する機能
RunningTasks on group resources	リソースグループに対し、オペレーションタスク・スクリプトを自動的に実行する機能
Parameter store	複数のリソースで共有可能な、認証キーやIDなど秘匿情報やプレインテキストデータを階層的に管理して保存、参照する機能
OS patch management	複数のリソースまたはリソースグループに対し、パッチ適用などを実行する機能
Meintenance windows	タスク実行をスケジューリング化し実行する機能
Consistent Configuration	ステートマネージャを使用した一貫した設定・メンテナンス機能

Remote Connect

インバウンド接続設定がないプライベートサブネットのEC2インスタンスにSessionManagerを使ってリモート接続を行う。 まず、SSMへのアクセス権限を付与したIAMロールを作成する。IAMロールメニューを選択し、「ロールの作成」ボタンを押下する。

ロールを使用するサービスとして、「EC2」を選択する。

「AmazonEC3RoleforSSM」ポリシーをアタッチする。

ロール名を入力し、「ロールの作成」ボタンを押下する。

続いて、プライベートサブネットにインバウンド接続のないセキュリティグループを設定したEC2を作成する。 EC2メニューから「インスタンスの作成」ボタンを押下する。

マシンイメージとして「Amazon Linux2(HVM), SSD Volume Type」を選択する。

Note

これらのマシンイメージにはデフォルトで「SSMエージェント」がインストールされている。

適当なインスタンスタイプを選択する。

プラベートサブネットがあるVPCを選択し、上記で作成したIAMロールを設定する。

Note

LaunchするとEC2からSSM APIへポーリングが実行されるようになる。

ストレージはデフォルトのまま設定しておく。

後の手順でインスタンスを識別しやすいようにタグを設定しておく。

インバウンド接続設定がないセキュリティグループ(デフォルトのもの)を設定する。

「起動」ボタンを押下し、インスタンスを実行する。

Note

キーペアは特に設定せず実行して良い。

インスタンスが実行された後、「SystemManager」サービスの「マネージドインスタンス」メニューを選択し、作成したインスタンスが表示されていることを確認する。

SessionManagerを利用して、セッションを開始する。「セッションマネージャ」メニューを選択し、「セッションの開始」ボタンを押下する。

接続対象のインスタンスを選択する。

コンソールが開き、コマンドが実行可能になる。

SSHデーモンをストップしても継続してコンソール処理できることを確認する。

Resource Group

Todo

Systems Managerを使ったリソースグループ設定のやり方を記載する。

Insight & Dashboard

Note

Microsoftのブラウザだとうまくいかないので注意

Remote Connect の手順中に作成したEC2インスタンスのインベントリ情報を収集し、QuickSightを通して可視化する。 データの収集はEC2インスタンスにインストールされたSSMエージェントに対し、 ステートマネージャーが30分毎に情報送信を指示する。収集した情報は、 インベントリがS3へ集約して転送する。S3に集約されたデータはAWS Glueが12時間に1度の頻度でクローリングしてデータベースを構築する。 このデータベースに対し、AWS Athenaがクエリを実行して、QuickSightにより可視化する流れとなる。

なお、収集できるインベントリデータは、EC2にインストールされているアプリケーションパッケージの一覧やバージョン等。 また、マシンスペックといったインスタンスの情報やOSのバージョンなどが収集される。定期的なOSのアップデート対象やセキュリティ脆弱性対象の確認などの用途に適している。

以下順次環境構築していく。

SystemsManagerサービスを選択し、「インベントリ」メニューを選択後、「セットアップインベントリ」ボタンを押下する。

インベントリの名前を入力し、ターゲットでインスタンスを手動選択し、 Remote Connect で作成したEC2インスタンスを選択する。

収集するパラメータは以下の通り設定する。

選択後、「セットアップインベントリ」ボタンを押下する。

「マネージドインスタンス」メニューから、収集設定したインスタンスを選択し、「インベントリ」タブを選択する。

インベントリタイプで、収集設定したパラメータが表示されることを確認する。

Note

なお、インベントリの収集頻度はステートマネージャーメニューから確認できる。

続いて、収集するインベントリ情報を保存するためのS3バケットの作成とアクセス制御設定を行う。「S3」サービスから「バケットの作成」ボタンを押下する。 バケット名を入力し、東京リージョンを選択する。

プロパティはデフォルトのまま、「次へ」ボタンを押下する。

アクセス許可は「パブリックアクセスを全てブロック」を選択し、「次へ」ボタンを押下する。

「バケットの作成」ボタンを押下して、バケットを作成する。

作成したバケットにアクセスポリシーを設定する。バケットを選択し、「アクセス権限」タブを選択する。

以下の通り、ポリシーエディタに設定する。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SSMBucketPermissionsCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::debugroom-sample-ssm-inventory"
       },
       {
            "Sid": " SSMBucketDelivery",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::debugroom-sample-ssm-inventory/*/accountid=XXXXXXXXXXXXXXX/*",
            "Condition": {
                "StringEquals": {
                   "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
       }
    ]
}

リソースデータを同期し、作成したS3バケットへデータ送信を行う。「インベントリ」メニューを選択し、「リソースデータの同期」ボタンを押下する。

「リソースデータの同期の作成」ボタンを押下する。

同期名を入力し、先ほど作成したバケット名を入力する。バケットのリージョンを選択して、「作成」ボタンを押下する。

「インベントリ」メニューを再度押下して。作成したインベントリの「詳細ビュー」タブから作成したリソースデータの同期を行う。 ロールの作成などしばらく時間がかかるので、時間を置いた後再度実行する。

インベントリタイプで、設定したインベントリデータが表示されれば、作成が成功する(S3にデータがあるか確認する)。

Note

このデータ同期により、Athena でクエリするために必要な Glue クローラや Glue データカタログの作成も合わせて行われる。Glueクローラーでは指定した場所にあるデータを自動で解析してAmazon Athenaのデータベースとテーブルを作成する。

作成したデータをQuickSightで可視化する(初回はサインアップ手順から)。QuickSightサービスを選択し、「Sign up for QuickSight」ボタンを押下する。

「Standard」エディションを選択する。

S3バケットがある同じリージョンを選択し、QuickSightアカウント名及び、Emailを入力する。

以下にチェックを入れ、「完了」ボタンを押下する。

• Enable autodiscovery of data and users in your Amazon Redshift, Amazon RDS, and AWS IAM services
• Amazon Athena
• AmazonS3(バケットも忘れずに設定する)

「Amazon QuickSightに移動する」ボタンを押下する。

画面左上部の「新しい分析」ボタンを押下する。

画面左上部の「新しいデータセット」ボタンを押下する。

「Athena」を選択する。

「データソース名」を入力し、「データソースを作成」ボタンを押下する。

テーブルを選択する。

Note

ここでは上述の「リソース同期の作成」時に、S3上に転送されたインベントリデータをAWS Glueがクロールしてテーブルを自動構築している。クロール頻度など変更したい場合は、「AWS Glue」サービスなどを選択して変更すること。

「Visualize」ボタンを押下する。

以下の要領で、インベントリデータを可視化する。

1. QuickSight のメイン画面左上の「追加」を選択し、「ビジュアルを追加する」を選択する。 シート上にビジュアルフィールドが表示される。
2. 左下のビジュアルタイプの枠右上にある円グラフのアイコンをクリックする。
3. 左側のフィールドリストから architecture を選択し、ドラッグ&ドロップして「グループ/色」に配置する。ビジュアルフィールドに円グラフが表示される。これは対象となる全サーバの全パッケージ一覧のアーキテクチャの比率を示している。

また、以下の要領で、別のインベントリデータを可視化する。ここでは、特定パッケージの特定バージョンのソフトウェアがいくつ導入されているのか表を新しく作成する。

1. 再度 QuickSight のメイン画面左上の「追加」を選択し、「ビジュアルを追加する」を選択する。シート上にビジュアルフィールドが表示される。
2. ビジュアルタイプから左下のほうにある「テーブル」を選択する(ピボットテーブルではなく)。
3. グループ化の条件に「name」 「version」、値に「name」をドラッグ&ドロップする。値に配置したものは name(カウント) となり、合計件数を表している。対象サーバが 1つだとカウントはすべて1になるが、異なるバージョンのソフトウエアが複数サーバに導入されていると、どのバージョンがいくつ導入されているのかを把握することが可能になる。これにフィルタを追加することで、特定ソフトウェアだけを表示することができる。

Running Tasks

SystemsManager を使用することで、多数の EC2インスタンスへのコマンドの実行を一括して行うことができる。ここでは、 Remote Connect の手順中に作成したEC2インスタンスに対し、コマンドの実行を行う。 「コマンドの実行」メニューを選択し、「コマンドを実行」ボタンを押下する。

「AWS-RunShellScript」を選択する。

実行コマンドを入力する。

ターゲットとなるインスタンスを選択する。インスタンスのタグや、手動選択、作成したリソースグループの選択も可能である。ここでは、作成したインスタンスを手動で選択する。

その他は特に入力せず、「コマンド実行」ボタンを押下する。

実行されたコマンドの結果が表示される。

2500文字までなら出力結果を確認することができる。

Paramter Store

Overview

パラメータストアはパスワードやデータベース文字列、ライセンスコードなどアプリケーションに直接実装せず環境変数を経由して設定するデータ等を一元的に管理するためのサービスである。 特に多くのEC2インスタンスやECSタスク上にデプロイされたアプリケーションなどで同一のデータを参照したい場合有効であり、またデータは階層構造をとることができる。 データ値はプレーンテキストまたはAWS KMSを使用して暗号化データとして使用でき、暗号化や復号化も同時に実行する。パラメータストアの参照はIAMにより細かくアクセス制御が可能であり、 以下のAWSサービスから利用可能である。

• Amazon EC2
• Amazon ECS
• AWS Lambda
• AWS CloudFormation
• AWS CodeBuild
• AWS CodeDeploy

また、暗号化や通知、モニタリング、監査を行うため、以下のサービスと連動して機能する。

• AWS KMS
• Amazon SNS
• Amazon CloudWatch
• AWS CloudTrail

従来のパラメータストアでは、データサイズが4KBまで、スループット上限は規定範囲内だったが、2019年4月のアップデートでアドバンスドパラメータオプションが導入 され、 10000を変えるパラメータの作成、最大8KB、スループットの上限緩和(デフォルト40tpsから最大1000tpsまで)の拡張がなされた。 ただし、アドバンスドパラメータオプションは有料となるため注意すること。

標準パラメータストアの設定

1. AWSコンソール上から、Systems Managerを選択し、「パラメータストア」メニューから「パラメータの作成」ボタンを押下する。

2. パラメータ名と値を設定し、「作成」ボタンを押下する。

Note

ここで設定したパラメータを参照する方法は、 CodeBuild Localの実行 を参照のこと。

OS patch management

Todo

パッチマネージャーを使ったOSパッチ管理方法を記載する。

Maintenance windows

メンテナンスウィンドウとコマンド実行機能を利用して、OSのパッチを適用するコマンドを実行する。「メンテナンスウィンドウ」メニューから「メンテナンスウィンドウの作成」ボタンを押下する。

メンテナンスウィンドウ名を入力する。ここで、未登録のターゲットのチェックは外しておく。

スケジュールを指定する。確認のため、ここでは30分に一回、クーロンスケジュールビルダーで設定しておく。

「メンテナンスウィンドウの作成」ボタンを押下する。

作成したメンテナンスウィンドウを選択し、「アクション」ボタンからターゲットの登録を選択する。

ターゲット名を入力する。

適用対象とするインスタンスを選択する。ここでも同じくインスタンスのタグや、手動指定、リソースグループを使った指定ができるが、手動でインスタンスを選択する。

続いて、メンテナンスウィンドウを選択し、「タスク」タブから、「タスクを登録する」ボタンを押下する

「run command タスクの登録」を選択する。

「タスクの名称」を入力する。

コマンドのドキュメントには、「AWS-RunPatchBaseline」を選択し、優先度を1に設定する。

上記で作成したターゲットを指定する。「レート制御」゙は一度に 2つのインスタンスの処理を実行し、全ての処理が失敗した場合にのみタスクを停止する(途中で失敗するインスタンスがあった場合でも全てのインスタンスに一度は処理が実行される)よう 並行性ターゲットを1に指定し、誤差閾値を100%に設定する。

IAMロールは「Systems Manager用のサービスにリンクされたロールを使用する」を選択する。

パラメータのOperationには「Install」を指定し、「run commandタスクの登録」ボタンを押下する。

登録後、指定時刻になると、実行されるので、履歴タブから結果を確認する。

Consistent Configuration

Todo

ステートマネージャを使った設定・実行方法を記載する。

Landing Zone

Overview

マルチアカウントのポリシーやパーミッションをコントロールし自動で簡単に設定できるソリューション(無償)。ControllTownerの前身。 構成する各サービスの利用料は負担する形になる。

ControlTower

Overview

マルチアカウントに対応したセキュアな環境(ガードレール)を簡単に設定・管理

設定されたガードレール

ルール	ガイダンス	カテゴリ	動作
ログアーカイブの保存時に暗号化を有効にする	必須	監査ログ	予防
ログアーカイブのアクセスログ作成を有効にする	必須	監査ログ	予防
ログアーカイブへのポリシーの変更を不許可にします	必須	モニタリング	予防
ログアーカイブへのパブリック読み取りアクセスを不許可にする	必須	監査ログ	検出
ログアーカイブへのパブリック書き込みアクセスを不許可にする	必須	監査ログ	検出
ログアーカイブの保持ポリシーを設定する	必須	監査ログ	予防
CloudTrail への設定変更を不許可にします	必須	監査ログ	予防
CloudTrail イベントと CloudWatch logs を統合する	必須	モニタリング	予防
利用可能なすべてのリージョンで CloudTrail を有効にする	必須	監査ログ	予防
CloudTrail ログファイルの整合性検証を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された CloudWatch への変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された AWS Config アグリゲーションへの変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Config への設定変更を不許可にします	必須	監査ログ	予防
利用可能なすべてのリージョンで AWS Config を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された AWS Config ルールへの変更を不許可にします	必須	Control Tower のセットアップ	予防
EBS 用に最適化されていない EC2 インスタンスタイプの起動を許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされていない EBS ボリュームを許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされた EBS ボリュームの暗号化を有効にする	強く推奨	データセキュリティ	検出
AWS Control Tower によって設定された IAM ロールへの変更を不許可にします	必須	Control Tower のセットアップ	予防
MFA なしで IAM ユーザーへのアクセスを許可しない	選択的	IAM	検出
AWS Control Tower によって設定された Lambda 関数への変更を不許可にします	必須	Control Tower のセットアップ	予防
MFA なしで IAM ユーザーへのコンソールアクセスを許可しない	選択的	IAM	検出
RDP を介したインターネット接続を許可しない	強く推奨	ネットワーク	検出
SSH を介したインターネット接続を許可しない	強く推奨	ネットワーク	検出
RDS データベースインスタンスへのパブリックアクセスを許可しない	強く推奨	データセキュリティ	検出
RDS データベーススナップショットへのパブリックアクセスを許可しない	強く推奨	データセキュリティ	検出
暗号化されたストレージではない RDS データベースインスタンスを許可しない	強く推奨	データセキュリティ	検出
ルートユーザーとしてのアクションを許可しない	強く推奨	IAM	予防
ルートユーザーのアクセスキーの作成を許可しない	強く推奨	IAM	予防
S3 バケットのクロスリージョンレプリケーションを許可しない	選択的	データセキュリティ	予防
MFA なしで S3 バケットでの削除アクションを許可しない	選択的	データセキュリティ	予防
ルートユーザーに対して、MFA を有効化する	強く推奨	IAM	検出
S3 バケットへのパブリック読み取りアクセスを不許可にする	強く推奨	データセキュリティ	検出
S3 バケットへのパブリック書き込みアクセスを不許可にする	強く推奨	データセキュリティ	検出
バージョンが有効かされていないS3 バケットを許可しない	選択的	データセキュリティ	検出
Amazon SNS によって設定された AWS Control Tower への変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された Amazon SNS のサブスクリプションへの変更を不許可にします	必須	Control Tower のセットアップ	予防

AWS運用Memo

■エンタープライズ運用ユースケース・パターン

• サーバを可視化

  • SSM Inventoryを使った可視化
  • SSMエージェントをインストールすれば、オンプレミスマシンの情報収集も可能
  • EC2→SSM Inventory→S3→Athena→QuickSight
  • AWS Configとの連携により違反状況を検知・通知も可能

• 実行一括オペレーション

  • SSM RunCommandによる規定操作の一括実行

• サーバログイン操作の事前許可と事後確認

  • SSM SessionManager上で、許可された人が許可されたサーバに許可された時間にログイン可能なように制御
  • 実行コマンド履歴の事後確認

• インスタンスを指定時間帯のみ起動する

  • SSM MaintenanceWindowによるスケジューリング
  • Instance Scheduler

• メモリ使用率などを収集する監視エージェント(CloudWatch統合Agent)の一括設定

• セキュリティパッチの適用

  • SSM PatchManagerを使用して一定のルールで全社のサーバに適用する

• ソフトウェアライセンスの管理

  • SSM Inventoryを使って情報収集し、LicenceManagerで突きあわせ。

• Control Tower

■マルチアカウントとして、以下のようにアカウントを分離することを推奨。

• 請求アカウント
• 共有サービス
• セキュリティ&監査

■ 運用の種類と目的

• システム運用

  • イベント管理
  • インシデント管理
  • セキュリティ管理

• 保守運用

  • 構成管理
  • パッチ管理
  • ライセンス管理
  • 変更管理
  • 資産管理
  • リリース管理
  • テスト

• 障害対応

• サービス運用