小林  治

小林 治

1598281440

[小ネタ] Sumo LogicでCloudTrailのログからAWSアカウントIDを取得する #sumologic

背景

Sumo LogicでCloudTrailの監視をしていると、たまに「このログ、どのAWSアカウントから出たものだろう?」と思うことがあります。

というのも、そもそもCloudTrailのログには、「どのAWSアカウントIDで発生したログか」という情報がフィールドとして存在しないためです。

userIdentity.accountId として記録されている情報はあくまで「操作したユーザの情報」であるため、日常的は問題ない場面も多そうですが、AWSの仕組み上別のAWSアカウントに権限を移譲できるため、完全ではありません。

  • AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法 - AWS Identity and Access Management

そもそも全てのログにこの情報が記録されるわけでもないので、まるっと見たい時にはちょっと使いづらいです。

じゃあどうするか、と考えてみたところ、簡単な方法がみつかりました。

ログファイル名(S3オブジェクトファイル名)からパースすれば良さそうです。

解説

上述したAWSドキュメントにあるように、CloudTrailのログは下記のフォーマットのオブジェクト名をもっています。

AccountID_CloudTrail_RegionName_YYYYMMDDTHHmmZ_UniqueString.FileNameFormat

実際にはこれに、デフォルトのプレフィクスが追加されるため、バケット名を除けば例えば以下のような感じになります。

#aws #オペレーション #sumo logic

What is GEEK

Buddha Community

[小ネタ] Sumo LogicでCloudTrailのログからAWSアカウントIDを取得する #sumologic
小林  治

小林 治

1598281440

[小ネタ] Sumo LogicでCloudTrailのログからAWSアカウントIDを取得する #sumologic

背景

Sumo LogicでCloudTrailの監視をしていると、たまに「このログ、どのAWSアカウントから出たものだろう?」と思うことがあります。

というのも、そもそもCloudTrailのログには、「どのAWSアカウントIDで発生したログか」という情報がフィールドとして存在しないためです。

userIdentity.accountId として記録されている情報はあくまで「操作したユーザの情報」であるため、日常的は問題ない場面も多そうですが、AWSの仕組み上別のAWSアカウントに権限を移譲できるため、完全ではありません。

  • AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法 - AWS Identity and Access Management

そもそも全てのログにこの情報が記録されるわけでもないので、まるっと見たい時にはちょっと使いづらいです。

じゃあどうするか、と考えてみたところ、簡単な方法がみつかりました。

ログファイル名(S3オブジェクトファイル名)からパースすれば良さそうです。

解説

上述したAWSドキュメントにあるように、CloudTrailのログは下記のフォーマットのオブジェクト名をもっています。

AccountID_CloudTrail_RegionName_YYYYMMDDTHHmmZ_UniqueString.FileNameFormat

実際にはこれに、デフォルトのプレフィクスが追加されるため、バケット名を除けば例えば以下のような感じになります。

#aws #オペレーション #sumo logic

Alverta  Crist

Alverta Crist

1590389692

Aggregating SSH logs from your servers into SumoLogic

This tutorial covers aggregating SSH access logs from your server fleet into SumoLogic using Teleport

#morioh #ssh #sumologic #teleport

笹田  晃

笹田 晃

1598021580

Sumo LogicにGuardDutyのログをS3から取り込む方法

Sumo LogicはAmazon GuardDutyのログを取り込んでダッシュボード表示させる機能があります。

しかし公式には、CloudWatch Logsから収集する方法しか書かれていません。

  • Amazon GuardDuty - Sumo Logic
  • Collect Logs for the Amazon GuardDuty App - Sumo Logic

このやり方を使うためには、Sumo GuardDuty events processor というAWS Lambda関数をデプロイして、CloudWatch Events経由でSumo Logicに送信する必要があります。

AWS Serverless Application Repository からデプロイできるので手軽ではありますが、管理するリソースも増えますし、導入にハードルを感じる方もいらっしゃるんじゃないでしょうか。

一方で皆さんご存じのように、GuardDutyにはログをS3に記録する設定が可能です。

この仕組みを使って、S3バケットに保存されたGuardDutyのログをSumo Logicに取り込むことももちろん可能です。以下、その手順をご説明します。

#aws #sumo logic #amazon guardduty #aws kms

笹田  晃

笹田 晃

1598257276

[初心者向け] Terraform で default セキュリティグループをあつかう

最近 Terraform に入門した西野です。

ひととおりチュートリアルを終え、いざ自分で .tf ファイルを書く段階になった途端、default セキュリティグループのルールを抹消したい欲求がフツフツとわき起こってきました。よくあることだと思います。 *1

Output Variables) などを用いてこねくり回さないとだめなのだろうか…?と思いつつ公式ドキュメントを眺めていたところ、ちょうど良い Resource を見つけました。

aws_default_security_group

default セキュリティグループをあつかうための Resource は下記の aws_default_security_group です。

Resource: aws_default_security_group)

通常の Resource の場合 Terraform は .tf ファイルにおける宣言によって対象の実体を 作成 します。

この aws_default_security_group の場合、既に存在する default セキュリティグループを 取り込む 動きをし、引数でわたされた設定で上書きするようです。

やってみた

新たな VPC を作成し、当該 VPC の dafault セキュリティグループからインバウンド/アウトバウンドルールを削除してみます。

main.tf

resource "aws_vpc" "vpc" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "vpc"
  }
}

resource "aws_default_security_group" "default" {
  vpc_id = aws_vpc.vpc.id
}

output "default_security_group_id" {
  value = aws_default_security_group.default.id
}

#aws #terraform #初心者向け #amazon vpc #小ネタ

小林  治

小林 治

1598274360

[小ネタ] CloudFrontでクエリ文字列を転送しているときのInvalidationにはクエリ文字列を忘れないように注意しよう

はじめに

清水です。タイトルのとおりなのですが、Amazon CloudFrontでクエリ文字列をオリジンに転送するよう設定している場合でInvalidation(ファイルの無効化)を行う際には、Invalidation対象のパスにクエリ文字列を含める必要があります。(クエリ文字列部分のワイルドカードの利用も可です。)Cookieやヘッダーをオリジンに転送している場合は対象となるパスのみを指定すれば良いため、混乱することがあるかもしれません。というか私が混乱してしまったので備忘録がてらまとめてみたいと思います。

CloudFrontでクエリ文字列をオリジンに転送している際のInvalidationについて確認してみた

Amazon CloudFront開発者ガイドを確認すると、その旨記載があります。

  • ファイルの無効化 - Amazon CloudFront
  • 「無効にするファイルの指定」 > 「クエリ文字列の転送」

以下では実際に、オリジンにクエリ文字列を転送するCloudFrontを構築、Invalidation時の挙動を確認してみました。

確認する環境について

オリジンはEC2にApache+PHPをインストールし、リクエスト時の時間とクエリ文字列を出力するコード(qs.php)を配置しました。コードは以下になります。

qs.php

<?php
date_default_timezone_set('Asia/Tokyo');
echo date("Y/m/d H:i:s");
echo "\n";
echo $_SERVER['QUERY_STRING']
?>

実際にアクセスすると、以下のような出力となります。

  $ curl "http://ec2-XXX-XXX-XXX-XXX.ap-northeast-1.compute.amazonaws.com/qs.php?foo=bar"
2020/05/31 10:55:48
foo=bar

#aws