joshlarsen/aws-reconマルチスレッド対応の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レート制限（スロットリング）に遭遇する可能性が非常に高くなります。