AWS Systems Manager（SSM）を利用して、運用管理を楽にする　インベントリ編

齊藤弘樹

2年前

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

AWS SystemsManager(SSM)にはさまざまな機能が備わっている反面、サービス自体がわかりにくくなっている印象があります。

「AWS SystemsManagerは便利」と知ってはいるけど、実際に使っていない方もいるのではないでしょうか。

この記事では、以下の項目について紹介していきます。

AWS SystemsManagerについて
AWS SystemsManagerのユースケース
ユースケースに沿った構築例紹介

AWS SystemsManagerは多機能ですので、今回の記事では“インベントリ”機能に注目します。

AWS SystemsManager（SSM）を利用して、運用管理を楽にしよう

■AWS SystemsManagerとは

AWS Systems Manager は、ハイブリッドクラウド環境のための安全なエンドツーエンドの管理ソリューションです。Systems Manager により、アプリケーションとリソースの管理が簡略化され、オペレーション上の問題の検出と解決にかかる時間が短縮されるほか、AWS リソースを大規模かつ安全に管理できるようになります。　（AWS公式ドキュメントより）

主な管理領域は4つです。

業務管理
アプリケーション管理
変更管理
ノード管理

今回重点的に紹介するインベントリ機能は“ノード管理”に含まれます。ちなみにAWS Systems Managerのノード管理だけでも、管理および設定するために以下の機能が提供されているのです。

フリートマネージャー
コンプライアンス
インベントリ(←今回はコレに注目)
ハイブリッドアクティベーション
セッションマネージャー
Run Command
ステートマネージャー
パッチマネージャー
ディストリビューター

■AWS SystemsManagerインベントリとは

今回使用するAWS SystemsManagerインベントリはAWS SystemsManagerの機能の一つで、AWSでのコンピューティング環境を可視化するサービスです。

インベントリ機能を使用することで、Agentがインストールされたマネージドノードからメタデータを収集することができます。収集されたメタデータをS3バケットに保存し、その他のAWSサービスと組み合わせることで、ソフトウェアを実行しているノード、ソフトウェアポリシーに必要な設定、および更新が必要なノードをすばやく判断することが可能です。

【収集するメタデータタイプ】

アプリケーション: アプリケーション名、発行元、バージョンなど。
AWS コンポーネント: EC2 ドライバー、エージェント、バージョンなど。
ファイル: 名前、サイズ、バージョン、インストール日、変更および最新アクセス時間など。
ネットワーク設定の詳細: IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスクなど。
Windows 更新: Hotfix ID、インストール者、インストール日など。
インスタンスの詳細: システム名、オペレーティングシステム (OS) 名、OS バージョン、DNS、ドメイン、ワークグループ、OS アーキテクチャなど。
サービス: 名前、表示名、ステータス、依存サービス、サービスのタイプ、起動タイプなど。

※SystemsManagerインベントリは、マネージドノードからメタデータのみを収集します。インベントリは、機密情報またはデータにアクセスすることはありません。

■AWS SystemsManagerのユースケース

AWS SystemsManagerはクラウド環境だけではなく、オンプレミス環境も含めたハイブリッドクラウド環境の管理を容易にする機能が多く提供されています。

以下のユースケースは、AWS SystemsManagerの機能を利用した例の一部です。（AWS Systems Manager 徹底活用～エンタープライズのユースケースから～ | AWS Summit Tokyo 2019より）

ソフトウェア構成情報の収集と可視化(←今回はコレを紹介)
サーバ群でコマンドを一括実行して結果を確認する
サーバログイン操作の事前許可ち事前確認
スケジューリング
構成管理
セキュリティパッチの適用を徹底する
所有ライセンス数と実際の利用数を管理する

ユースケースから構築例紹介

ここからは先述したユースケースの中から、ソフトウェア構成情報の収集と可視化に関する構築例を紹介します。

【具体的なユースケース】

対象サーバにインストール済みのソフトウェアのバージョンを確認したい
脆弱性が見つかったソフトウェアの導入状況を確認したい

【実現したいこと】

対象サーバ上のソフトウェア構成をキーワードでフィルタリングしグラフ化

■データ収集・可視化ハンズオン

～全体の流れ～

VPCの作成
IAMロールの作成
EC2インスタンスの作成
S3バケットの作成
Systems Managerの準備
　5-1. SSMインベントリの準備
　5-2. SSMリソースデータの同期
QuickSightの作成

■VPCの作成

リージョン内の他アカウントからの情報も取得する想定を試したいので、VPCを2つ用意します。

設定値は以下の通りです。※私は個人的な理由からシンガポールリージョンを使用します。

項目	設定値
作成するリソース	VPCなど
名前タグの自動生成	saitou-ssm-handson-VPC-A(任意)
IPv4 CIDR ブロック	10.0.0.0/16
IPv6 CIDR ブロック	IPv6 CIDR ブロックなし
アベイラビリティゾーン(AZ)の数	1
第1アベイラビリティゾーン	ap-southeast-1a
パブリックサブネットの数	1
プライベートサブネットの数	0
1aのパブリックサブネットCIDR	10.0.1.0/24

↓

もう一つVPCを作成します。設定値は以下の通りです。

項目	設定値
作成するリソース	VPCなど
名前タグの自動生成	saitou-ssm-handson-VPC-B(任意)
IPv4 CIDR ブロック	10.0.0.0/16
IPv6 CIDR ブロック	IPv6 CIDR ブロックなし
アベイラビリティゾーン(AZ)の数	1
第1アベイラビリティゾーン	ap-southeast-1b
パブリックサブネットの数	1
プライベートサブネットの数	0
1aのパブリックサブネットCIDR	10.0.2.0/24

↓

VPCの作成は以上です。

■IAMロールの作成

EC2にアタッチするIAMロールを作成します。AWSで提供されているAMIの一部にはAWSリソースを管理するためのSSMエージェントがプリインストールされています。

EC2インスタンスにインストールされているSSMエージェントががSSM APIに対してポーリングできるように、IAMロールでポリシーの付与が必要です。

設定値は以下の通りです。

項目	設定値
信頼されたエンティティタイプ	AWS のサービス
ユースケース	EC2
ロール名	saitou-ssm-handson-IAMRole

↓

↓AWSが用意する“AmazonSSMManagedInstanceCore”を利用したいので、“AmazonSSMManagedInstanceCore”をフィルタリングし、該当のポリシーにチェックを入れ、「次へ」をクリックしましょう。

AmazonSSMManagedInstanceCore

↓名前を入力し、画面右下にある「ロールを作成」を押してください。

↓

“Role saitou-ssm-handson-IAMRole created.”と表示されましたら、IAMロールの作成は完了です。

■EC2インスタンスの作成

今回のハンズオンではEC2インスタンスをVPC-Aに3個、VPC-Bに3個の合計6個起動させます。※自身の状況に応じて、1個ずつの計2個でも構いません。

6つも起動させるのは、QuickSightでEC2の構成情報を見る際に、見栄えをよくするためだけです。

まずはVPC-A内に置くEC2インスタンスを作成します。設定値は以下の通りです。

項目	設定値
名前	saitou-ssm-handson-EC2-1(任意)
AMI	Amazon Linux 2
アーキテクチャ	64ビットx86
インスタンスタイプ	t2.micro
キーペア	任意
VPC	saitou-ssm-handson-VPC-A
サブネット	saitou-ssm-handson-subnet-public1
パブリック IP の自動割り当て	有効化
ファイアウォール	セキュリティグループを作成する
セキュリティグループ名	saitou-ssm-handson-SG-1
IAMインスタンスプロフィール	saitou-ssm-handson-IAMRole
インスタンス数	3

EC2のダッシュボード画面から「インスタンスを起動」をクリックしてください。

↓

↓“高度な詳細”でIAM インスタンスプロフィールに、作成したIAMロールを選択してください。

↓最後にインスタンス数に「3」と入力し、「インスタンスを起動」をクリックしましょう。

↓作成したEC2インスタンスを確認してみると、名前がすべて“saitou-ssm-handson-EC2-1”です。名前が編集できますので、「EC2-2」と「EC2-3」と変更しておきます。

↓

次にVBC-Bに置くEC2インスタンスを作成します。設定値はほぼ一緒です。

項目	設定値
名前	saitou-ssm-handson-EC2-4(任意)
AMI	Amazon Linux 2
アーキテクチャ	64ビットx86
インスタンスタイプ	t2.micro
キーペア	任意
VPC	saitou-ssm-handson-VPC-B
サブネット	saitou-ssm-handson-subnet-public1
パブリック IP の自動割り当て	有効化
ファイアウォール	セキュリティグループを作成する
セキュリティグループ名	saitou-ssm-handson-SG-2
IAMインスタンスプロフィール	saitou-ssm-handson-IAMRole
インスタンス数	3

↓

↓VBC-Bに置くEC2インスタンスには以下のコマンドスクリプトを入力しておきます。高度な詳細の“ユーザーデータ”に以下のスクリプトを貼り付けてください。

#!/bin/bash
sudo -s
yum update -y
amazon-linux-extras enable php7.4
yum install -y php php-mbstring php-mysqlnd php-zip php-fpm php-gd php-xml

↓インスタンス数を「3」と入力し、「インスタンスを起動」をクリックしましょう。

↓こちらのEC2インスタンスも名前を変更しておきましょう。

↓

EC2の作成が完了しました。

■S3バケットの作成

インベントリデータを集約して保管するS3バケットを作成します。設定値は以下の通りです。

項目	設定値
バケット名	saitou-ssm-handson-s3
AWSリージョン	シンガーポールリージョン（ap-southeast-1）

「バケットを作成」をクリックしてください。

↓

↓「バケットを作成」をクリックします。

SSWインベントリのデータを保管できるように、バケットポリシーを編集します。作成したバケットを検索し、クリックしてください。

↓“アクセス許可”タブ内のバケットポリシーの「編集」を押してください。

↓

↓以下のポリシーを貼り付けてください。みなさんとバケット名が違うと思います。変更箇所は、11行目の“あなたのS3バケット名”と20行目の“あなたのS3バケット名”・“12桁のアカウントID”です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SSMBucketPermissionsCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::あなたのS3バケット名"
        },
        {
            "Sid": " SSMBucketDelivery",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::あなたのS3バケット名/*/accountid=12桁のアカウントID/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

貼り付けが完了しましたら、「変更の保存」を押しましょう。

下準備が長くなりましたが、ようやくSSMの設定です。

■SSMインベントリの準備

AWS Systems ManagerでAWSリソースを管理するためには、事前にAgentのインストールが必要です。しかし、一部のAmazonMachineImagesではプリインストールされた状態で起動しますので、インストール作業が不要です。

そして、AmazonSSMManagedInstanceCoreポリシーがアタッチされたEC2は、SSM APIに対しポーリングします。

ここまでの工程でエージェントのインストール作業やSystems Managerの設定を行っていませんので、エージェントが動いている実感が持てないかもしれませんね。

AWSSystems Managerのコンソール画面を見てみましょう。左ペインの「フリートマネージャー」をクリックしてください。

↓左ペインの「フリートマネージャー」をクリックしてください。

作成したEC2インスタンスがSystems Managerにマネージドノードとして管理できるようになっていますね。

本題の構成情報が確認できるように、インベントリをセットアップします。左ペインの「インベントリ」をクリックし、「セットアップインベントリ」を押してください。

設定値は以下の通りです。

項目	設定値
名前	saitou-ssm-handson-Inventory
ターゲット	インスタンスの手動選択（6個）

↓

↓他はデフォルトの設定のまま、「セットアップインベントリ」を押します。

インベントリで収集されたデータを確認してみましょう。「インベントリ」をクリックし、“対応するマネージドインスタンス”に指定したEC2インスタンスが確認できるはずです。

試しにEC2インスタンス一つをクリックしてください。インベントリタブを押してみると、導入済みのソフトウェアの一覧が表示されます。

↓

■SSMリソースデータの準備

各インスタンスのインベントリデータをまとめるために、“リソースデータの同期”を行います。

設定値は以下の通りです。

項目	設定値
同期名	saitou-ssm-handson-ResourceData
バケット名	saitou-ssm-handson-s3
バケットプレフィックス	resourcedata
バケットのリージョン	このリージョン
KMSキーARN	（空白）