目次
記事説明
この記事では、「Management & Governance」分野の重要なサービスである、
AWS Configについて説明します。
↓Management & Governanceの重要なサービス一覧
・Amazon CloudWatch
・AWS CloudFormation
・AWS CloudTrail
・AWS Config
・AWS Systems Manager
参考：【AWS Black Belt Online Seminar】 AWS CloudTrail & AWS Config
参考：【AWS Black Belt Online Seminar】AWS Config
※こちらから画像も引用しています。
AWS Configの位置づけ
Amazon Management Toolsとして、5つの機能が提供されています。
１．リソースプロビジョニング
⇒テンプレート定義によるインフラプロビジョニングの自動化
主なサービス：AWS CloudFormationなど
２．構成管理
⇒パッケージの導入、ソフトウェアとリソースのコンフィグレーション、パッチ適用
主なサービス：AWS Systems Managerなど
３．モニタリング
⇒AWSリソースやアプリケーションに対する、モニタリング、アラーム、
メトリクスダッシュボード、ログ、イベント管理
主なサービス：Amazon CloudWatch
４．ガバナンスとコンプライアンス
⇒リソースインベントリ、構成変更管理、ユーザ操作とAPI呼び出しの記録、
セルフマネージドなITカタログ
主なサービス：AWS CloudTrail、AWS Config
５．リソース最適化
⇒コスト低減、パフォーマンス向上、セキュリティの改善に対する推奨事項の自動提供
主なサービス：AWS Trusted Advisor
このうち、AWS Configは
Amazon Management Toolsの中のガバナンスとコンプライアンス機能として用いられます。
AWS Configの概要
概要としては、
「AWSリソースのレポジトリ情報から、リソースの変更履歴、構成変更を管理する」
サービスで、構成情報を元に、現在のシステムがあるべき状態になっているかを評価します。
構成情報は定期的にスナップショットとして、S3に保存されます。
AWS Configは3つの要素で構成されています。
１．Configuration Stream
リソースが作成、変更、削除される度に作成され、構成ストリームに追加される。
SNSトピック連携可能。
２．Configuration History
任意の期間における各リソースタイプの履歴。
指定したS3バケットにエクスポートされる。
３．Configuration Snapshot
あるポイントにおける、リソースタイプのスナップショット。
自動で定期的あるいは、変更トリガで作成され、S3にエクスポートされる。
AWS Configが対応しているAWSリソース一覧
全てのサービス（リソース）に対応しているわけではありませんが、
主要サービスであるEC2やRDSには対応しておりますし、
統制的な観点では、IAMやACMに対応しています。
※2020年9月現在では、26サービスに対応していることを確認しています。
AWS Configの監視の流れ
１．First Discovery
AWS Configを有効にすると、はじめにサポートされるリソースに対し、
ディスカバリーが実行され、CI(ConfigurationItem)を作成する。
２．Periodically Discovery
定期的に構成変更が無いかをディスカバリーを実行。
３．Configuration History
6時間毎にディスカバリー結果を出力(構成変更がある場合)。
４．Configuration Snapshot
定期的にSnapshotを出力。手動でスナップショットを取得することも可能。
AWS Config Rulesについて
AWS Config Rulesにより、ポリシー適合の評価をすることができます。
準拠すべきルールを事前に設定しておき、そのルールに沿った構成変更が行われているかを評価します。ルールは、AWSが提供している基本的なものと、カスタムルールの２種類があります。
１．AWS Managed Rules
・AWSにより定義・提供され、AWSにより運用される。
必要最低限のベーシック・ルールであり、下記のようなルールがある。
– AMIの確認 ・・・実行中のインスタンスで使用されているAMIは指定したものか
– RootアカウントのMFA ・・・ MFAが有効になっているか
– EBSボリュームの暗号化 ・・・ アタッチ済みのEBSボリュームが暗号化されているか
– CloudTrailの有効化 ・・・ CloudTrailが有効になっているか
– EIPのアタッチ ・・・ EIPがすべて割り当てられているか
– SSHの制限 ・・・ 受信SSHトラフィックのIPアドレスが制限されているか
– EC2 in VPC ・・・ VPCに属しているか
– タグの付与 ・・・ タグが付与されているか
– ポート設定 ・・・ 指定したポートへの着信TCPトラフィックを制限しているか
２．Customer Managed Rules
・自分でルールを作成可能
・管理は作成者が実施
実際にはLambda Functionを作成し、評価ルールを作成することになり、
評価結果はAWS Configに引き渡される。
AWS Config Rule Development Kit（RDK）と呼ばれる、
カスタムルールの作成を支援する開発キットがある。
また、ルール違反のリソースに対して、ルールに関連付けた修正アクションを行うことが可能。
例）S3バケットがパブリック読み込みを許可している場合、修正アクションで無効にする。
AWS Config Rulesの評価実行タイミングについて
ルールの評価実行は２つのタイミングがあります。
１．Event-Based Evaluations
・関連リソースが作成、変更された際にルールの評価が実行される
・Scoped by changes to:
・Tag Key/Value
・Resource types
・Specific resource ID
例）新規で作成するEC2に、必ずTagが付けれられているかの評価
２．Periodic Evaluations
・任意のタイミング
・AWS Config がコンフィグレーションスナップショットを取る際にルールの評価が実施される
例）CloudTrailが有効になっているかどうかの評価
AWS Configのベストプラクティス
★記録対象について
１．すべてのアカウントとリージョンでAWS Configを有効にする。
⇒すべての操作を記録する。
⇒ミスがあればすぐに気づけるように、環境を整えておく。
２．すべてのリソースタイプについて、設定変更を記録する。
⇒新しく追加されたリソースタイプも自動で記録対象となるため、もれなく監視ができる。
３．グローバルリソース(CloudFrontなど)は１リージョンで記録を有効にする。
⇒重複して記録されるのを防ぐ。
★保存先について
４．安全なS3バケットにヒストリーとスナップショットを保存する。
⇒AWSリソースの詳細情報も記録されるので、
特定の人しかアクセスできず、改ざんできない場所に保存する。
★マルチアカウント環境での利用について
５．Data aggregation機能を使って、管理アカウントから集中管理する。
６．Organizationsベースのaggregatorを使う。
⇒マルチアカウント環境では統制が取りにくい為、構成管理用アカウントから集中監視する。
まとめ
AWSのサービスの中で重要な位置づけである、AWSConfigに関する記事でした。
複数のサーバを管理するようになると、ルールに則った運用ができているかわからなくなってしまうので、こういったサービスを活用し、運用コストを下げていければ良いですね。
AWS Configに似ている監視機能として、CloudTrailというサービスもあります。
AWS Configとの大きな違いは下記の通りになります。
オペレーションからユーザアクティビティを監視する ⇒ CloudTrail
AWSリソースの変化から、ユーザアクティビティを監視する ⇒ AWS Config
宜しければ、下記の記事のご覧ください。
参考：AWS CloudTrail（Black Belt解説）
それでは、お読みいただきありがとうございました。
