
マルチスレッド対応のAWSインベントリ収集ツールで、セキュリティに関連するリソースとメタデータに焦点を当てています。
Rubyで書かれたマルチスレッド対応のAWSセキュリティ重視インベントリ収集ツール。
このツールは、大量のAWSリソース属性とメタデータを効率的に収集するために作成されました。AWS環境のセキュリティ設定と態勢に関連するほぼすべての情報を収集することを目的としています。
既存のツール(例:AWS Config)では、セキュリティ態勢を正確に測定するためのカバレッジと具体性(詳細なリソース属性データ、完全に解析されたポリシードキュメント、ネストされたリソース関係など)が不足しています。
AWS Reconは、自動リトライ(ネットワーク信頼性またはAPIスロットリングによる)、大量レスポンスの自動ページング(API呼び出しあたり100リソース以上)、マルチスレッドによる並列リクエストを活用して、大規模アカウントからの収集を処理します。
** 使用は推奨を意味するものではありません
AWS Reconには、ReadOnlyAccess権限を持つAWSアカウントのロールまたは認証情報が必要です。完全なAdministratorAccessは過剰な権限ですが、動作はします。SecurityAuditポリシーでは多くのサービスへのアクセスが不足しているため、十分ではありません。
Dockerバージョン19.x以上を使用して、何もインストールせずに事前構築済みイメージを実行できます。
すでにRubyがインストールされている場合(2.6.xまたは2.7.x)、Ruby gemをインストールすることもできます。
AWS Reconは、Dockerコンテナ経由でローカル実行するか、Ruby gemをインストールして実行できます。
Dockerコンテナ経由で実行するには、必要なAWS認証情報をDocker run コマンドに渡します。例:
$ docker run -t --rm \
-e AWS_REGION \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-v $(pwd)/output.json:/recon/output.json \
darkbitio/aws_recon:latest \
aws_recon -v -s EC2 -r global,us-east-1,us-east-2
ローカルで実行するには、最初にgemをインストールします:
$ gem install aws_recon
Fetching aws_recon-0.5.17.gem
Fetching aws-sdk-3.0.1.gem
Fetching parallel-1.20.1.gem
...
Successfully installed aws-sdk-3.0.1
Successfully installed parallel-1.20.1
Successfully installed aws_recon-0.5.17
または、bundleを使用してGemfileに追加します:
$ bundle add aws_recon
Fetching gem metadata from https://rubygems.org/
Resolving dependencies...
...
Using aws-sdk 3.0.1
Using parallel-1.20.1
Using aws_recon 0.5.17
AWS Reconは、実行環境で現在利用可能なAWS認証情報を活用します(要件を参照)。複数のアカウントから収集する場合は、aws-vaultのようなツールを使用して異なる認証情報を管理するとよいでしょう。
$ aws-vault exec profile -- aws_recon
プレーンな環境変数でも問題なく動作します。
$ AWS_PROFILE=<profile> aws_recon
aws-vault管理の認証情報を使用してDockerコンテナから実行する場合(標準出力に出力):
$ aws-vault exec <vault_profile> -- docker run -t --rm \
-e AWS_REGION \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
darkbitio/aws_recon:latest \
aws_recon -j -s EC2 -r global,us-east-1,us-east-2
aws-vault管理の認証情報を使用してDockerコンテナから実行し、ファイルに出力する場合、いくつかの要件を満たす必要があります。まず、Dockerが指定したパス(またはその上位パス)をバインドマウントできる必要があります。次に、出力を保存する空のファイル(例:output.json)を作成する必要があります。これは、実行時にそのファイルのみがDockerコンテナにマウントされるためです。例:
空のファイルを作成します。
$ touch output.json
aws_reconコンテナを実行し、出力ファイルを指定します。
$ aws-vault exec <vault_profile> -- docker run -t --rm \
-e AWS_REGION \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-v $(pwd)/output.json:/recon/output.json \
darkbitio/aws_recon:latest \
aws_recon -s EC2 -v -r global,us-east-1,us-east-2
最初は-vまたは--verboseフラグを使用して、収集実行中のステータスとアクティビティを確認するとよいでしょう。
冗長モードでは、コンソール出力に次のように表示されます:
<thread>.<region>.<service>.<operation>
tプレフィックスは、特定のリクエストがどのスレッドで実行されているかを示します。リージョン、サービス、操作は、現在進行中のリクエスト操作とその場所を示します。
$ aws_recon -v
t0.global.EC2.describe_account_attributes
t2.global.S3.list_buckets
t3.global.Support.describe_trusted_advisor_checks
t2.global.S3.list_buckets.acl
t5.ap-southeast-1.WorkSpaces.describe_workspaces
t6.ap-northeast-1.Lightsail.get_instances
...
t2.us-west-2.WorkSpaces.describe_workspaces
t1.us-east-2.Lightsail.get_instances
t4.ap-southeast-1.Firehose.list_delivery_streams
t7.ap-southeast-1.Lightsail.get_instances
t0.ap-south-1.Lightsail.get_instances
t1.us-east-2.Lightsail.get_load_balancers
t7.ap-southeast-2.WorkSpaces.describe_workspaces
t2.eu-west-3.SageMaker.list_notebook_instances
t3.eu-west-2.SageMaker.list_notebook_instances
Finished in 46 seconds. Saving resources to output.json.
# S3とEC2のグローバルリソース、およびus-east-1とus-east-2を収集
$ AWS_PROFILE=<profile> aws_recon -s S3,EC2 -r global,us-east-1,us-east-2
# S3とEC2のグローバルリソース、およびus-east-1とus-east-2を収集
$ AWS_PROFILE=<profile> aws_recon --services S3,EC2 --regions global,us-east-1,us-east-2
# 出力をS3バケットに保存
$ AWS_PROFILE=<profile> aws_recon \
--services S3,EC2 \
--regions global,us-east-1,us-east-2 \
--verbose \
--s3-bucket my-recon-bucket
# ホームリージョンをus-east-1以外にしてS3バケットに保存
$ AWS_PROFILE=<profile> aws_recon \
--services S3,EC2 \
--regions global,us-east-1,us-east-2 \
--verbose \
--s3-bucket my-recon-bucket:us-west-2
OpenCSPM形式(NDJSON)の出力例。
$ AWS_PROFILE=<profile> aws_recon -l \
-s S3,EC2 \
-r global,us-east-1,us-east-2 \
-f custom
または
$ AWS_PROFILE=<profile> aws_recon -j \
-s S3,EC2 \
-r global,us-east-1,us-east-2 \
-f custom > output.json
権限に関連するAPI例外は、ほとんどの場合サイレントに無視されます。これらのエラーは通常、以下のいずれかのケースが原因です:
verboseモードでは、出力に例外ログが表示されます:
t2.us-east-1.EC2.describe_subnets.0
t4.us-east-1.SSM.describe_instance_information.0
t6.us-east-1.SecurityHub.InvalidAccessException <-----
t2.us-east-1.EC2.describe_addresses.0
t4.us-east-1.SSM.describe_parameters.0
t1.us-east-1.GuardDuty.list_detectors.0
-qコマンドラインオプションを使用すると、これらの例外を再スローして、アクセス問題のトラブルシューティングを容易にできます。
Traceback (most recent call last):
arn:aws:sts::1234567890:assumed-role/role/my-audit-role is not authorized to perform:
codepipeline:GetPipeline on resource: arn:aws:codepipeline:us-west-2:1234567890:pipeline
(Aws::CodePipeline::Errors::AccessDeniedException)
例外を引き起こした正確なAPI操作は、スタックトレースの最終行に示されています。必要なアクセスを解決できない場合は、-xまたは--not-servicesでそれらのサービスを除外するか、-qオプションを使用せずに収集を続行します。
AWS Reconは、世界中のエンドポイントに対して多数のAPI呼び出しを行う際のI/O課題を克服するために、複数のスレッドを使用します。
IAM、Shield、Supportなどのグローバルサービスの場合、リクエストはマルチスレッド化されません。S3モジュールは、各バケットが完全なメタデータを収集するためにいくつかの追加呼び出しを必要とするため、マルチスレッド化されています。
リージョナルサービスの場合、リージョン内のサービスごとにスレッド(スレッド制限まで)が生成されます。デフォルトでは最大8スレッドが使用されます。アカウントのリソースが多くのリージョンに分散している場合、-t X(Xはスレッド数)でスレッドを増やすと速度が向上する可能性があります。
AWS Reconは、新規/空のアカウントでも、すべての標準リージョン(GovCloud、中国リージョンを除く20リージョン)でサポートされているサービスをクエリするだけで、最低約2,000回のAPI呼び出しを行います。デフォルト(8)よりも多くのスレッドを有効にすると、大規模アカウントでAPIレート制限(スロットリング)に遭遇する可能性が非常に高くなります。
Reconは自動的にバックオフし、APIレスポンスのリトライ制限を尊重します。収集中に長い一時停止が発生する場合、これが原因である可能性があります。-dまたは--debugオプションを使用して収集を再試行し、ワイヤトレースを観察してスロットリングされているかどうかを確認してください。定期的にレート制限を受ける場合は、スレッド数を減らすか、AWSにレート制限の引き上げをリクエストすることを検討してください。
ほとんどのユーザーは、収集対象を関連するサービスとリージョンに制限したいでしょう。除外せずに実行すると、アカウントで有効化されているすべてのリージョンからすべてのリソースを収集しようとします。
$ aws_recon -h
AWS Recon - AWS Inventory Collector (0.5.17)
Usage: aws_recon [options]
-r, --regions [REGIONS] スキャンするリージョン(カンマ区切り、デフォルト: 全て)
-n, --not-regions [REGIONS] スキップするリージョン(カンマ区切り、デフォルト: なし)
-s, --services [SERVICES] スキャンするサービス(カンマ区切り、デフォルト: 全て)
-x, --not-services [SERVICES] スキップするサービス(カンマ区切り、デフォルト: なし)
-c, --config [CONFIG] サービスとリージョンの設定ファイルを指定(例: config.yaml)
-b, --s3-bucket [BUCKET:REGION] 出力ファイルをS3バケットに書き込み(デフォルト: '')
-o, --output [OUTPUT] 出力ファイルを指定(デフォルト: output.json)
-f, --format [FORMAT] 出力形式を指定(デフォルト: aws)
-t, --threads [THREADS] 最大スレッド数を指定(デフォルト: 8、最大: 128)
-l, --json-lines NDJSON/JSONL形式で出力(デフォルト: false)
-u, --user-data EC2インスタンスのユーザーデータを収集(デフォルト: false)
-z, --skip-slow 遅い操作をスキップ(デフォルト: false)
-g, --skip-credential-report IAMクレデンシャルレポートの生成をスキップ(デフォルト: false)
-j, --stream-output JSON Linesを標準出力にストリーム出力(デフォルト: false)
-v, --verbose クライアントの進捗と現在の操作を出力
-q, --quit-on-exception APIエラーが発生した場合に収集を停止(デフォルト: false)
-d, --debug ワイヤトレース情報を含むデバッグ出力
-h, --help このヘルプ情報を表示
出力は常に何らかのJSON形式(JSON LinesまたはプレーンJSON)です。出力はファイルに書き込まれるか(デフォルト)、-jを使用して標準出力に書き込まれます。
S3バケットに書き込む場合、JSON出力は自動的にgzipで圧縮されます。
手動有効化リージョンを有効にしている場合:
STSを使用してアカウントにロールを引き受ける場合は、それらのリージョンに対してAWS Reconを実行できるよう、ロールを引き受ける元のアカウントでv2 STSトークンを有効にする必要があります。
バージョン1のトークンは、デフォルトで利用可能なAWSリージョンでのみ有効です。これらのトークンは、アジアパシフィック(香港)などの手動有効化リージョンでは機能しません。バージョン2のトークンはすべてのリージョンで有効です。ただし、バージョン2のトークンは長くなり、トークンを一時的に保存するシステムに影響を与える可能性があります。
静的アクセスキー/シークレットを使用している場合、STSトークンのバージョンに関係なく、これらのリージョンから収集できます。
現在のサービスごとの「カバレッジ」は以下にリストされています。カバレッジのないサービスは、将来的に追加される予定です。PRは歓迎します。:)
AWS Reconは、AWSアカウントのセキュリティ態勢を判断する上で関連するすべてのリソースとメタデータを収集することを目的としています。ただし、実際にセキュリティ態勢を検査するわけではありません。それは、AWS Reconの出力を入力として受け取る他のツールの役割です。
AWS Reconの主な動機の1つは、メンテナンスと拡張が容易なツールを構築することでした。特定のサービスのカバレッジを改善できると思われる場合、そのためのPRを歓迎します。Rubyに中程度の知識がある方であれば、既存のコレクターが使用するパターンを模倣して、特定のサービスをクエリし、結果をリソースコレクションに追加することができます。
このリポジトリをクローンします:
$ git clone [email protected]:darkbitio/aws-recon.git
$ cd aws-recon
RVMを使用している場合は、スティッキーなgemsetを作成します:
$ rvm use 2.7.2@aws_recon_dev --create --ruby-version
bin/setupを実行して依存関係をインストールします。その後、rake testを実行してテストを実行します。bin/consoleを実行してインタラクティブなプロンプトを開き、実験することもできます。
このgemをローカルマシンにインストールするには、bundle exec rake installを実行します。新しいバージョンをリリースするには、version.rbのバージョン番号を更新し、bundle exec rake releaseを実行します。これにより、バージョンのgitタグが作成され、gitコミットとタグがプッシュされ、.gemファイルがrubygems.orgにプッシュされます。
AWS Reconは、以下のツールの背後にある優れた人々とチームの卓越した作業に触発されました: