AWS Config(1)Configの概要

AWS Configとは

AWS Configは、リソースごとの設定項目を生成し、履歴としてこれを保持するため、全ての変更を追跡することが可能で、AWSリソース間の関係と設定の履歴などを確認することができる。

  • リソースの設定が最適であるか
  • 現在のスナップショットの取得
  • リソース設定の取得
  • 設定履歴の取得
  • リソース間の関係の表示
  • 通知

これらの機能を用いて、リソースの管理監査とコンプライアンス設定変更の確認とトラブルシューティングセキュリティ分析などを行うことができる。

設定項目は、S3バケットに蓄積することが可能で、データはJSON形式で、S3に6時間ごとに送信される。また、リソースが変更されたタイミング等で、Amazon SNSを用いてEメール等で通知することも可能である。

AWS Configは、マルチアカウントマルチリージョンの データ集約 に対応しており、複数のアカウントやリージョンの設定、コンプライアンスデータを1つのアカウントに集約することができる。

AWS Configの概念

設定履歴と設定項目、スナップショット、レコーダ

設定履歴は、特定期間の特定リソースに関する設定項目のコレクションである。また、設定項目は、アカウント内のサポートされているAWSリソースの属性(メタデータ、関係、設定、関連イベントなど)を記録したものである。設定スナップショット は、設定項目のコレクションで、記録対象のリソースの全体像を示す。スナップショットは、S3 Bucketに配信が可能。

設定レコーダは、(標準設定では)Configがサポートしている全てのリソースの設定項目の評価と保存を行う。設定レコーダをオフにすると設定変更トリガによる評価は実行されない。一方で、定期実行トリガは引き続き指定した間隔で実行される

設定ストリーム

設定ストリームは、設定項目の自動更新リストで、リソースの作成や変更、削除が行われる度に、Amazon SNSを使用して通知を行うことができる。

ルール

AWS Configでは、望ましい設定をルールとして定めることができ、これに違反しているリソースに対しては、非準拠 のフラグを立てる。ルールは、事前に用意されたマネージドルールのほかに、ユーザが自ら作成したカスタムルールを適用することもできる。これらのルールは、リソースの設定変更時に評価されるのか、それとも定期的に評価されるのかを定義することができる。

AWS Configの仕組み

AWS Configは、サポートされているAWSリソースを検出し、リソースごとに設定項目を生成し、その記録を履歴として保持する。Configはリソースごとに、DescribeもしくはListのAPIコールによって、リソースの全ての変更を追跡する。Configルールを利用することで、定期的にこのルールに照らして、リソースの設定の評価を行うことができる。

また、この設定項目は、S3バケット もしくは Amazon SNS に配信することができる。SNSへ配信時のメッセージタイプは以下の通り。

メッセージタイプ 内容
ComplianceChangeNotification コンプライアンスタイプの変更時
ConfigRulesEvaluationStarted リソースの評価開始時
ConfigurationSnapshotDeliveryStarted スナップショット配信開始時
ConfigurationSnapshotDeliveryCompleted スナップショット配信完了時
ConfigurationSnapshotDeliveryFailed スナップショット配信失敗時
ConfigurationHistoryDeliveryCompleted 設定履歴配信完了時
ConfigurationItemChangeNotification リソース変更時
OversizedConfigurationItemChangeNotification SNSの最大サイズ超過時

AWS Configのセットアップ

AWS ConfigはCloudFormationに対応しているため、CloudFormation経由でConfigをセットアップすることができる。

サービスロールの有効化

以下のサービスロールを有効化することで、AWSリソースの読み込み権限 および S3への書き込み権限Config に、IAMとSystemManagerへの書き込み権限Config Remediation にそれぞれ付与する。

Resources:
  ServiceLinkedRoleForConfig:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: config.amazonaws.com
      Description: A service-linked role required for AWS Config to access your resources.
  ServiceLinkedRoleForConfigRemediation:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: remediation.config.amazonaws.com 
      Description: A service-linked role required for AWS Config Remediation to access your resources.

Configの有効化

DeliveryChannelConfigurationRecorder を作成する。

Resources:
  ConfigDeliveryChannel:
    Type: AWS::Config::DeliveryChannel
    Properties:
      Name: default
      S3BucketName: !Ref S3ForConfig
      SnsTopicARN: !Ref SnsTopicARN
  ConfigConfigurationRecorder:
    Type: AWS::Config::ConfigurationRecorder
    Properties:
      Name: default
      RecordingGroup:
        AllSupported: true
        IncludeGlobalResourceTypes: true
      RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig

すでにAWS Configをセットアップ済みの状態で上記テンプレートを実行すると、 the maximum number of delivery channels エラーが発生する。その場合は既存の DeliveryChannel を削除した上で、上記テンプレートを再度実行する。

aws configservice delete-delivery-channel --delivery-channel-name default
aws configservice delete-configuration-recorder --configuration-recorder-name default

S3バケットの作成

設定情報 (履歴ファイルやスナップショット)を保存するために使用する、Amazon S3 バケットと、それに紐づくバケットポリシーを作成する。

Resources:
  S3ForConfig:
    Type: 'AWS::S3::Bucket'
    DeletionPolicy: Retain
    Properties:
      BucketName: !Sub defaultsecuritysettings-config-${AWS::Region}-${AWS::AccountId}
      LifecycleConfiguration:
        Rules:
          - Id: ExpirationInDays
            ExpirationInDays: 60
            Status: Enabled
      PublicAccessBlockConfiguration: 
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  S3BucketPolicyForConfig:
    Type: AWS::S3::BucketPolicy
    Properties: 
      Bucket: !Ref S3ForConfig
      PolicyDocument:
        Version: 2012-10-17
        Id: !Ref S3ForConfig
        Statement:
          - Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action:
              - 's3:GetBucketAcl'
              - 's3:ListBucket'
            Resource:
              - !GetAtt S3ForConfig.Arn
          - Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action:
              - 's3:PutObject'
            Resource:
              - !Join
                - ''
                - - !GetAtt S3ForConfig.Arn
                  - /AWSLogs/
                  - !Sub ${AWS::AccountId}
                  - /Config/*
            Condition:
              StringEquals:
                s3:x-amz-acl: bucket-owner-full-control

CloudFormation Launch Stack URL

以下のボタンから上のCloudFormationテンプレートを実行することが可能である。ソースコードは、aws-cloudformation-templates/security – GitHub にて公開。

作成されるAWSサービス CloudFormationテンプレート
セキュリティサービス全般 cloudformation-launch-stack
Configのみ cloudformation-launch-stack

モニタリング

他のAWSサービスを利用して、AWS Configのリソースをモニタリングすることができる。例えば、Amazon SQSAmazon CloudWatch Eventsを利用することで、AWSリソースが作成、変更、削除された際に通知を受け取ることが可能となる。

AWS RDS(1)Relational Database Serviceの概要

RDSとは

RDSは、AWS内でRDBSを簡単に設定、運用、スケールできるサービスで、データベースのセットアップやパッチ適用、バックアップなどの管理タスクを自動化している。対応しているRDBSは、Amazon AuroraMySQLMariaDBOracleMicrosoft SQL ServerPostgreSQLの6種類である。一部制限事項も存在するため、この制限事項とのトレードオフが許容できない場合は、EC2上でRDBSを稼働させることも検討する。

管理負荷を軽減

RDBSにわずか数分でアクセス可能で、CloudWatchによる監視にも対応しているため、パフォーマンスの問題を簡単に検出することが可能である。また、ソフトウェアのパッチが自動的に適用されるために、常に最新の状態が維持されている。

パフォーマンス

汎用(SSD)ストレージプロビジョンドIOPS(SSD)ストレージから選択することが可能である。

スケーラビリティ

最大32vCPUおよびRAM244GiBまで拡張することが可能で、数分以内にスケーリングすることができる。また、ストレージサイズも柔軟に拡大が可能で、稼働中にダウンタイムなしに最大16TBまでストレージの拡張を行うことができる。また、リードレプリカを使用(=Amazon AuroraMySQLMariaDBPostgreSQLのみ対応)することで、読み込み負荷の高い処理をスケールアウトすることができる。

可用性と耐久性

自動バックアップ機能によって自動的(=1日に1回)に、もしくは任意の時点のスナップショットを保存することもでき最大35日(デフォルトは7日間保持)まで保存可能。また、RDは、5分に1回トランザクションログを保存しているため、これを用いて新たなインスタンスを起動(ポイントインタイムディカバリ)が可能。マルチAZ配置オプションを使用することで、異なるAZのスタンバイインスタンスにデータを複製し、可用性を向上させることができ、ハードウェア障害が発生した場合には、自動でフェールオーバされる。DNSでCNAMEが書き換えられ切り替えには数分要する。なお、スナップショット実行時は、短時間I/Oが停止することに注意が必要

セキュリティ

KMSを使用してデータベースを暗号化することが可能。また、VPC上で稼働させることで独自のネットワーク上で外部と隔離された状態で稼働できる。

AWS EC2(3)AMIとインスタンス

AMI

AMI(Amazon Machine Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、

  • OSやアプリケーションなどのルートボリュームのテンプレート
  • 起動を許可するAWSアカウント
  • インスタンスにアタッチするボリュームのマッピング

などの情報が含まれている。

AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linuxは、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる

なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。

リージョンをまたがるコピー

作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。

$ curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'

AMIの作成

既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。

$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit

インスタンスからの Linux AMI の作成

ストレージ

ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。

Instance Store

  • EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。ただし、再起動ではクリアされない
  • インスタンス停止(STOP)することができない。
  • 無料

instance store-backed のインスタンス

Elastic Block Store

  • ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
  • デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。
  • スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。スナップショットを取得する際には、EBSをアンマウントすることが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない
  • インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。

Amazon EBS-backed インスタンス

容量と性能

汎用SSD(gp2)のパフォーマンスは、ボリュームサイズに比例する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。

各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理(バースト)は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD(gp2)は、

  • 容量が33.4GB以下であれば、標準性能100IOPS
  • 容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
  • 容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持

と定義されている。また、スループットは、170GB以下では128 MB/秒170GBを超えると160MB/秒である。

インスタンス

概要

  • EC2は、1500MTUに加えてジャンボフレームをサポートする。
  • ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。

インスタンスのライフサイクル

インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。

インスタンスのライフサイクル

インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う

インスタンスの公開鍵

EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。

キーペアのインポート

インスタンスの時刻

デフォルトでは UTC(協定世界時間)時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。

vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

インスタンスの復旧

ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。

また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。また、ネットワークや電源のメンテナンスが実施される場合もある。

インスタンスメタデータ

実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。

http://169.254.169.254/latest/meta-data/