yuj1osm's tech blog

クラウドやセキュリティなど

AWS CloudTrail LakeにAWS Configの情報を取り込めるようになりました

AWS

AWS CloudTrail LakeにAWS Configの情報を取り込めるようになったので、検証してみました。

aws.amazon.com

アップデート概要

AWS CloudTrail Lake は、CloudTrailログを取り込むことでSQLベースの分析を可能にします。
今回のアップデートで、Configの設定項目情報も取り込めるようになりました。
CloudTrailはユーザベースの調査を可能にする一方、Configはリソースベースの調査を可能にするため、これらを統合して分析することが可能です。

検証

イベントデータストアの作成

CloudTrail Lakeの画面から、「イベントストアの作成」を押下します。

イベントデータストアに適当な名前を付けます。

イベントタイプは「設定項目」を選択します。

内容を確認し作成します。

イベントデータストアが作成されました。

Config設定項目情報の検索

セキュリティグループ「test-sg」を作成します。

CloudTrail Lakeで以下のクエリを使って検索すると、作成したセキュリティグループに関する情報を得ることができました。

クエリ

SELECT
    eventTime, eventData.configuration, eventData.resourceId, eventData.resourceName, eventData.resourceType
FROM
    <config-event-data-store-id>
WHERE
    eventTime > '2022-12-02 16:00:00' AND eventTime < '2022-12-02 17:00:00' AND eventData.resourceName = 'test-sg'
ORDER
    BY eventTime DESC;

2つのイベントデータストアを統合して検索

事前にCloudTrail用のイベントデータストアを作成しておきます。

今度はセキュリティグループ「test2-sg」を作成します。
以下のクエリにより、CloudTrail用のイベントデータストアをとConfig設定項目情報用のイベントデータストアを統合して検索できます。
結果を見ると、CloudTrailとConfigの両方の情報が得られていることが分かります。

クエリ

SELECT
    config.eventTime, config.eventData.configuration, config.eventData.resourceId, config.eventData.resourceName, config.eventData.resourceType, userIdentity.username, trail.eventName, trail.eventSource
FROM
    <config-event-data-store-id> AS config JOIN <trail-event-data-store-id> AS trail ON config.eventData.resourceName = element_at(trail.requestParameters, 'groupName') 
WHERE
    config.eventTime > '2022-12-02 17:00:00' AND config.eventTime < '2022-12-02 18:00:00'
ORDER
    BY config.eventTime DESC;

まとめ

AWS CloudTrail LakeにAWS Configの設定項目情報を簡単に取り込み、検索することができました。
さらに、CloudTrailとConfigを統合して検索することができ、分析がしやすくなったのではないかと思います。

AWS Organizationsのポリシー管理を委任できるようになりました

AWS

AWS Organizationsのポリシー管理を委任できるようになったので、検証してみました。

aws.amazon.com

アップデート概要

これまで、AWS Organizationsのポリシー管理は組織の管理アカウントでしかできませんでした。
今回のアップデートで、ポリシー管理をメンバーアカウントに委任できるようになりました。

検証

Organizationsの「設定」→「委任」を押下します。

こちらのエディタで、誰に何を許可するかを定義できます。

例えば、メンバーアカウントでOrganizationsの画面を表示しようとすると、以下のよう表示できません。

そこで、先ほどのエディタで以下のように定義します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<accountID>:root"
            },
            "Action": [
                "organizations:List*"
            ],
            "Resource": "*"
        }
    ]
}

<accountID>は委任するメンバーアカウントで、今回は<accountID>に「organizations:List*」を許可しています。

再度、メンバーアカウントでOrganizationsの画面を表示しようとすると、今度は表示できました。

まとめ

アカウントが増えてくると管理を委任したいが、組織の管理アカウントに気軽にログインさせたくないケースが出てくると思います。
今回のアップデートで、マルチアカウントの運用の幅も広がるのではないかと思います。

Amazon InspectorがAWS Lambdaの脆弱性スキャンに対応しました

AWS

Amazon InspectorがAWS Lambdaの脆弱性スキャンに対応したようなので、検証してみました。

aws.amazon.com

アップデート概要

Amazon Inspectorは脆弱性を管理するためのサービスで、Amazon EC2やAmazon ECRのコンテナイメージに、脆弱性が存在しないかを継続的にスキャンします。
今回新たに、AWS Lambda関数とAWS Lambda Layersの脆弱性スキャンに対応しました。
スキャン対象は、Java、NodeJS、および Pythonで記述された関数とレイヤーです。
スキャンタイミングは、Lambdaのデプロイ時、Lambdaの更新時、新しい脆弱性 ( CVE ) の公開時です。

検証

事前準備

Inspectorの画面です。
Lambdaの項目が増えています。

以前からInspectorを使用している場合は無効化になっているので、有効化する必要があります。

アカウント管理から、「有効化」→「Lambda標準スキャン」を押下します。

有効化されました。

Organizationを使っていれば、Inspector委任管理者アカウントから全アカウントまとめて有効化できます。
新しいメンバーアカウントを追加したときに、Lambdaスキャンが有効化になるように、「Lambda標準スキャン」にチェックを入れて保存しておきましょう。

検知させてみる

適当なLambda関数を作成します。

AWSから提供されている、「arn:aws:lambda:ap-northeast-1:249908578461:layer:AWSLambda-Python37-SciPy1x:118」レイヤーを追加してみました。

しばらくすると検知されました。

Lambda別画面で検出結果が見れます。

こちらは、全ての検出結果画面です。
脆弱性のタイトルから、検知の詳細を見ることができます。

まとめ

簡単にLambdaの脆弱性スキャンを行うことができました。
これまでambdaの脆弱性診断は、サードパーティ製品を使う必要がありましたが、ネイティブ機能で実施できる点はメリットだと思います。

Amazon CloudWatch Logsで機密データを保護できるようになりました

AWS

AWS re:Invent 2022が始まり、アップデートが増えてきました。
Amazon CloudWatch Logsで機密データを保護できるようになったようなので、検証してみました。

aws.amazon.com

アップデート概要

Amazon CloudWatch LogsはAWSが提供しているログ監視サービスです。
システムやアプリケーション、 AWSサービスからのログを一元化して監視することができ、検索や検知に活用できます。
今回はそのCloudWatch Logsに対して、データ保護ポリシーを適用することで、ログ中の機密データを検知して自動的にマスクできるようになりました。
HIPPA、GDPR、PCI-DSSといった規制にも役立つ機能です。

以下がユーザガイドになります。

docs.aws.amazon.com

保護できるデータの種類は以下にまとまっており、本記事の執筆時点では日本語対応はしていないようです。

docs.aws.amazon.com

検証

機密データを検知させてみる

ロググループを作成します。

「アクション」から「Create data protection policy」を押下します。

プルダウンで保護対象を選択します。 「EmailAddress」と「Name」を選択してみました。

適当なログストリームを作成して、サンプルのメールアドレスを流してみます。

アスタリスクでマスクされていることを確認できました。

次に氏名を流してみましたが、日本語氏名はマスクされないようです。

※アンマスクしたもの（アンマスク方法は後述）

機密データとして検知すると、警告表示が出ます。

「Data protection」というタブが追加されており、検知数を確認できます。

アンマスクしてみる

「Display」から「Temporarily unmask protection data」を押下するとアンマスクできます。

ただし「logs:Unmask」権限が必要なので、権限が無いと以下のようにエラーになります。
「ReadOnlyAccess」でもアンマスクはできませんでした。

IAMユーザに以下「logs:Unmask」権限を付与しましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "logs:Unmask",
            "Resource": "*"
        }
    ]
}

「logs:Unmask」権限を付与したIAMユーザで「Temporarily unmask protection data」を押下すると、以下のようにアンマスクされたログが確認できます。

検知ログの転送

検知ログはCloudWatch Logs、Kinesis Data Firehose、S3に送信することができます。
今回は、新たに作成したCloudWatch Logsのロググループに転送設定をしてみました。

以下のように新たにログを生成します。
検知は２件です。

※アンマスクしたものが以下です。

カウントが2件増え、合計4件になりました。

転送先のロググループのログストリームを確認してみると、検知した２件がどのカテゴリで検知したかを確認できます。
※黒塗りはAWSアカウントIDです。

機密データが紛れ込んだときに、気付けるようなアラートの実装も簡単にできそうです。

まとめ

セキュリティ監視の現場では、機密データはマスクして欲しいという要望は多いので、非常に良い機能だと思います。
日本語が未対応のため、今後のアップデートでさらに使いやすくなるのではないかと思います。

Session Managerのログ保存

AWS

前回、「Session Managerを使用したEC2接続」をご紹介しましたが、この機能を使ってコマンドログを取ることができます。
前回の記事の設定を流用します。

Session ManagerでコマンドログをS3に保存する

バケットを作成

ログ保存用のバケットを作成します。

暗号化は「Amazon S3 マネージドキー (SSE-S3)」を選択し、その他の設定はデフォルトのままにします。

IAMロールを設定

S3にログを保存するためのインラインポリシーをロールに追加します。

S3保存と暗号化に必要な権限を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::sessionmanager-log-bucket/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "*"
        }
    ]
}

ポリシー作成は公式ドキュメントが参考になります。

docs.aws.amazon.com

S3エンドポイントを作成

インターネットを経由しない閉じた環境でS3に接続するため、S3エンドポイントをGateway型で作成します。

インスタンスが配置されているVPCと、サブネットで指定しているルートテーブルを選択します。

Session Managerのログ設定を有効化

System Managerの画面からSession Managerのログ設定を有効化します。

S3へのログ転送と暗号化を有効化し、転送先のバケットを指定します。

Session Managerで接続

EC2の画面から、Session Managerで接続します。

適当なコマンドを入力し、終了します。

Session Managerの画面で、セッション履歴が確認できます。

バケットにログファイルが格納されています。

まとめ

Session Managerでコマンドログを取る方法を紹介しました。
今回はEC2と同一アカウントのS3に保存しましたが、ログを保存するアカウントを別途用意するとより安心です。
さらに、権限を正しく設定することで、ログの改ざんを防ぐことも重要になります。

Session Managerを使用したEC2接続

AWS

Session Managerを使用したEC2接続の方法を紹介します。

Session Managerとは

AWS Systems Managerという、AWSリソースの構成や変更を管理するサービスがあり、Session Managerはその1機能です。
Session Managerを利用することで、従来のSSHを使わずに、AWSマネジメントコンソールからEC2へ接続することができます。

docs.aws.amazon.com

何が嬉しいか

HTTPSで接続できるため、SSHキーの鍵管理や通信許可が不要

HTTPSは空いているけど、社内ルールでSSHが制限されている場合があります。
また、SSHキーの管理にも気を使わなければならないため、運用負担が大きいです。 Session ManagerはHTTPSで接続できるため、手軽に導入することができます。

踏み台サーバが不要

パブリックサブネットやプライベートサブネットに配置しているEC2へもアクセスできるため、踏み台サーバが不要になります。

パブリックIPが不要

EC2へパブリックIPを付与しなくても接続することができます。

前提条件

EC2にSSM Agentの導入が必要

Amazon Linux 2などデフォルトで導入されているケースがありますが、導入されていない場合は手動でインストールする必要があります。

EC2にSystem Managerへの適切な権限が必要

AWS管理ポリシー「AmazonSSMManagedInstanceCore」を含む権限が、インスタンスにアタッチされている必要があります。

インターネットを経由しない場合は、適切なVPCエンドポイントが必要

インターネットを経由しない完全に閉じた環境でSession Managerを使用する場合は、以下のVPCエンドポイントを用意し、それらにアタッチするセキュリティグループでインバウンド443ポートを許可する必要があります。

  • com.amazonaws.region.ssm
  • com.amazonaws.region.ec2messages
  • com.amazonaws.region.ssmmessages

Session Managerで接続してみる

IAMロールを作成

EC2がSystem Managerを使用するために、EC2にアタッチするIAMロールを作成します。
信頼されたエンティティタイプは「AWSのサービス」、ユースケースは「EC2」を選択します。

ポリシーは、AWS管理ポリシー「AmazonSSMManagedInstanceCore」を選択します。

ロール名を付けて、ロールを作成します。

EC2を作成

今回は、デフォルトでSSM Agentがインストールされている、Amazon Linux 2をプライベートサブネットに配置した構成にします。
任意の名前を付けて、Amazon Linux 2を選択します。

キーペアはなしを選択します。

プライベートサブネットを選択します。
セキュリティグループは、デフォルトでインバウンドSSHが設定されていますが、不要なので削除します。

インスタンスプロファイルは先ほど作成したロールを選択します。

インスタンスが起動できたので、一度接続を確認してみます。

VPCエンドポイントを設定していないので、この時点では接続できません。

セキュリティグループを作成

後に作成するVPCエンドポイント用のセキュリティグループを作成します。
インバウンドルールで、VPC CIDERからのHTTPSを許可します。

エンドポイントを作成

以下3つのエンドポイントを作成します。

  • com.amazonaws.region.ssm
  • com.amazonaws.region.ec2messages
  • com.amazonaws.region.ssmmessages

サービスから検索し、選択します。

EC2を配置しているVPCとサブネットを選択します。
セキュリティグループは先ほど作成したものを選択します。
ポリシーはデフォルトのフルカスタムのままにします。

同じ要領で他のエンドポイントを作成します。

Session Managerで接続

先ほどと同様に、EC2の画面からSession Managerで接続してみます。
今度は「接続」ボタンがアクティブになっているので、「接続」ボタンを押下します。

プライベートサブネットに配置したインスタンスに、Session Managerを使用して接続することができました。

まとめ

Session Managerを使用したEC2接続の方法を紹介しました。
設定項目が多いですが、順に追っていけばできるはずです。
うまくいかない場合は、ロールやセキュリティグループを見直してみてください。
セキュリティを考慮しながら、簡単にプライベートサブネットのインスタンスへ接続することができるため、ぜひ活用してみてください。

マルチアカウント構成とIAM設計

AWS

AWSアカウントを複数運用している組織は多いと思います。
今回はクロスアカウントアクセスを利用した、Jumpアカウント方式を紹介します。

各アカウントにIAMユーザを作成する問題点

AWSアカウントは用途ごとに分けた方が管理がしやすいです。
マルチアカウントの考え方については、以下が分かりやすいです。

https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf

例えば以下のように、開発/ステージング/本番と3つのアカウントがあったとします。
それぞれのアカウントにIAMユーザを作成すると、アカウントごとにログインが必要になります。
また、IAMユーザが増えていくことでユーザやポリシーの管理が煩雑になり、セキュリティ上のリスクも高まります。

クロスアカウントアクセスによるJumpアカウント方式

Jumpアカウントを用意し、IAMユーザをこのアカウントに集約することで、権限を整理しやすくなります。
利用者は、まずJumpアカウントにログインし、各アカウントへスイッチロールすることでログインすることができます。
各アカウントでどのような操作を許可するかは、スイッチ先のロールに対して必要な権限を付与すればよいです。

IAMの設計例

権限設計の切り口は様々ですが、チームリーダーはある程度の権限を持たせたいけどチームメンバーは権限を絞りたい、というのも一つの方法です。

以下のような設計にすると運用しやすくなると思います。

前提

  • 前述の開発/ステージング/本番の3面環境
  • admin01/admin02：Jumpアカウントの管理者
  • leader01：チームリーダー
  • member01：チームメンバー

設計ポイント解説

  • Jumpアカウントで、管理者グループ「JumpAdminGroup」、リーダーグループ「LeaderGroup」、メンバーグループ「MemberGroup」を作成し、IAMユーザを所属させる。
  • Jumpアカウントで、管理者ロール「Jump_AdminRole」を作成し、管理者グループ「JumpAdminGroup」からのみスイッチロールを許可する。
    ※管理者同士のクロスチェックや緊急時に対応できるようにするため、管理者権限を持つユーザは複数人いるとよいでしょう。
  • 管理者ロール「Jump_AdminRole」は、JumpアカウントのIAMユーザやグループの管理に使用する。
  • 開発環境/ステージング環境/本番環境で、リーダーロール「<env>_LeaderRole」、メンバーロール「<env>_MenberRole」、読み取り専用ロール「<env>_ReadOnlyRole」を作成する。
  • 読み取り専用ロール「<env>_ReadOnlyRole」は、リーダーとメンバーの両方がスイッチでき、設定確認のみの場合はこのロールを使うルールにする。
    ※設定確認するだけのために高い権限を与えていると、操作ミスで設定を変更してしまう可能性があるため、読み取り専用ロールは作成しておくとよいです。例えば、Linuxでずっとrootのまま作業しませんよね？
  • リーダーロール「<env>_LeaderRole」は、リーダーグループ「LeaderGroup」からのみスイッチロールを許可し、サポート問い合わせや課金情報閲覧などある程度の権限を与えておく。
  • メンバーロール「<env>_MemberRole」は、メンバーグループ「MemberGroup」からのみスイッチロールを許可し、開発運用に必要な権限のみ与えておく。

人員変更があれば、JumpアカウントでIAMユーザを作成/削除し、グループへの追加/削除をするだけです。
さらに、これらのグループやロールをCloudFormationで構成すると、自動化や管理がしやすくなります。

まとめ

マルチアカウントのIAM設計のうちJumpアカウント戦略について紹介しました。
マルチアカウントとIAMの設計はなかなか難しく、社内体制や事業拡大とともに変わっていくものです。
ユーザからの要望や組織の変化に合わせて、適宜見直していく運用が大事だと思います。