サイトアイコン 協栄情報ブログ

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

saitou-handson-ssm-inventory


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

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

 

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

 

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

 

 

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

 

 

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

■AWS SystemsManagerとは

 

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

 

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

 

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

 

 

 

■AWS SystemsManagerインベントリとは

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

 

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

 

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

 

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

 

 

■AWS SystemsManagerのユースケース

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

 

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

 

 

 

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

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

 

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

 

【実現したいこと】

 

 

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

 

~全体の流れ~

 

  1. VPCの作成
  2. IAMロールの作成
  3. EC2インスタンスの作成
  4. S3バケットの作成
  5. Systems Managerの準備
     5-1. SSMインベントリの準備
     5-2. SSMリソースデータの同期
  6. 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 (空白)

 

 

左ペインから「インベントリ」を押し、「リソースデータの同期」をクリックしてください。

 

 

↓「リソースデータの同期の作成」をクリックします。

 

 

↓設定値を入力しましたら、「作成」を押してください。

 

 

↓はじめは保留中ですが、数分すると成功となるはずです。

 

 

 

次に詳細ビュータブで“リソースデータの同期”プルダウンリストから、先ほど作成したものを選択してください。

 

 

 

ぐるぐると更新している挙動が表示されるかと思います。この間にAWS GlueがS3にアクセスするIAM ロールの作成、Glueクローラの作成、クローリングの実行が行われています。

 

更新が完了次第AWS Glueのテーブルを見てみると、Glueカタログのデータがまとめられているのが確認できます。

 

 

S3に対してリソースデータの同期が行われ、さらに AWS Glue カタログに登録された状態になりました。

 

 

 

■QuickSightの準備

収集したデータをQuickSightで可視化してみましょう。※初めて利用する方は、QuickSight アカウントの作成が必要です。

 

 

「QuickSight」と調べ、コンソール画面に移動しましょう。

 

 

↓左のツリーから「分析」をクリックし、「新しい分析」を押してください。

 

 

↓次に「新しいデータセット」を押します。

 

 

↓データソースは「Athena」を選択してください。

 

 

↓次の設定値を入力し、「データソースを作成」を押しましょう。

 

項目 設定値
データソース名 saitou-ssm-handson-Inventory

 

 

 

↓“aws_application”を選択して「選択」ボタンをクリックします。

 

項目 設定値
データベース 作成したS3バケット名の付いたデータベース
テーブル aws_application

 

 

↓「データクエリを直接実行」を選択して「Visualize」ボタンをクリックします。

 

 

↓表やグラフに編集ができる画面に移ります。

 

 

 

収集したデータを視覚化する準備が整いました。実際に使ってみます。

 

 

■動作確認

構築が完了しましたので、以下のユースケースに沿って試してみましょう。

 

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

 

 

ユースケース1:バージョン確認

ユースケース1の「対象サーバにインストール済みのソフトウェアのバージョンを確認」を試してみます。

 

例えばWordPressを実行するには、PHPバージョン7.4以上が推奨です。稼働中のEC2インスタンスにインストールされているPHPのバージョンをチェックしてみましょう。

 

 

まずはビジュアルタイプをテーブルで指定します。

 

 

↓左のツリーから「フィルター」を押し、「フィルターの追加」をクリックします。

 

 

↓フィルタリングで「name」を選択してください。

 

 

↓フィルタータイプを「カスタムフィルター」にします。

 

 

↓値に「php」と入力し、「適用」を押してください。

 

 

↓さいごに左のツリーから「視覚化」を押し、フィールドリストから「name」、「resourceid」、「version」を選択しましょう。

 

 

 

phpがインストールされているEC2インスタンスのソフトウェアバージョンが確認できました。

 

 

ユースケース2:ソフトウェアの導入状況確認

ユースケース2は「脆弱性が見つかったソフトウェアの導入状況を確認」を試してみます。

 

例えば脆弱性対策情報データベースで“OpenSSLの脆弱性”を見て、対象サーバのソフトウェアの導入状況を確認したいと想定しましょう。

 

 

↓ユースケース1で使用したフィルタリングで、値を「openssl」と入力しましょう。

 

 

 

脆弱性情報では“OpenSSL”のバージョンが3.0以上が対象でしたが、QuickSightで確認した結果、対象サーバには問題ないことがわかりました。

 

対象サーバの台数が少なければ、SSHなどで調べても時間がかかりませんよね。しかし、対象サーバが何十台、何百台と増えると、膨大な時間がかかります。

 

AWS SystemsManagerや他のAWSサービスを利用することで、管理運用が楽になりそうですよね。

 

 

まとめ:AWS Systems Manager(SSM)を利用して、運用管理を楽にする インベントリ編

AWS SystemsManagerはアプリケーションやインフラの管理を容易にするための、さまざまな機能が備わっています。

 

多機能なのですべてを理解するのには時間がかかりますので、ユースケースに照らしあわせて機能を取捨選択していきましょう。

 

 

参考リンク:AWS workshop studio

 

 

↓ほかの協栄情報メンバーもAWS SystemsManagerに関する記事を公開しています。ぜひ参考にしてみてください。

 

■Amazon QuickSight を使用したデータの可視化(motoishi)
https://cloud5.jp/quicksight/

 

■Systems Managerインベントリを使ってEC2のインベントリ情報帳票を作成する(luchang)
https://cloud5.jp/ssm-inventory/

 

■ハンズオン(AWS Systems Managerの実践)(okano)
https://cloud5.jp/handson-aws-systems-manager/

 

■SessionManagerで利用するエンドポイントのCFn構築(INAMURA)
https://cloud5.jp/construction_of_endpoints/

 

モバイルバージョンを終了