Open11

AWSの下回りの技術を調べてみる

ピン留めされたアイテム
noboru_inoboru_i

ECSやLambdaといった、実際にアプリケーションを動かすようなものではなく、
ログや監査、制限などの下回りの技術について、改めて調べてみる。

noboru_inoboru_i

IAM Access Analyzer
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/accessanalyzer_analyzer
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/what-is-access-analyzer.html

参考資料
https://dev.classmethod.jp/articles/iam-accessanalyzer-vs-iam-accessadvisor/
https://blog.serverworks.co.jp/tech/2020/07/01/iam_access_analyzer-2/

checkingの機能。
定期的に権限設定をチェックしてくれ、外部からのアクセスが可能になった場合には「アクティブ」としてマークしてくれる。
ただし、単体では通知はできないので、 Amazon EventBridge -> Amazon SNS といった流れを利用するらしい。

例えば、
IAM roleに対して、Switch roleできる権限があるとか、
S3に対して、アクセスが可能になっていたり。
(具体的には、よくわからなかった)

設定自体は、かんたんなので、とりあえず有効にしておくのが良さそう。

noboru_inoboru_i

Amazon EventBridge
https://aws.amazon.com/jp/eventbridge/

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access-analyzer-eventbridge.html

EventBridge は Amazon CloudWatch Events の新しいバージョンです。
CloudWatch Events と同じと思って良さそう。
AWS上のイベントに反応して、別のサービス(SNSとか)を起動したり。
外部SaaSのイベントに反応することもできそう。(例としては、ZendeskやShopifyなどが挙げられている)

一つ前の "IAM Access Analyzer" と、 EventBridgeをつなげて、それをAmazon SNSで通知する設定例。
https://dev.classmethod.jp/articles/reinvent2019-aws-iam-access-analyzer-monitoring-with-amazon-eventbridge/

noboru_inoboru_i

AWS CloudTrail
https://aws.amazon.com/jp/cloudtrail/
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudtrail

AWS上のユーザ(IAMアカウントなど)の動作に対してログを保存しておくことができる。(監査目的が多そう?)
また、一部のサービスに対しては、より詳細な「データイベント」を保存しておく事もできる。
例えば、「S3のオブジェクトが追加された」、「Lambdaが実行された」など。

ログは、CloudTrails自体(CloudTrail console?)とS3に保存される。
CloudWatch Logsに転送することもでき、ここから通知なども行える。

noboru_inoboru_i

AWS Key Management Service (KMS)
https://aws.amazon.com/jp/kms/
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/kms_key

暗号化キーを作成できる。
ここで作成したキーを利用して、RDSやCloudTrailなどのデータ保存の際の暗号化を行うことができる。

IAM policyを設定した上で作成するので、利用できる箇所を限定できる。

AWS CloudTrail によって、利用されたタイミングを確認できる。

KMS自体についての、わかりやすい解説
https://dev.classmethod.jp/articles/10minutes-kms/

noboru_inoboru_i

Service-Linked Roles
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/using-service-linked-roles.html
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_service_linked_role

解説記事
https://dev.classmethod.jp/articles/aws-iam-service-linked-role/
https://dev.classmethod.jp/articles/iam-service-linked-roles-cloudformtion/

例えば、EC2のAutoScalingではスケールアウト/インのトリガーにCloudWatchアラームを利用しています。
このように「そのサービスから他のAWSサービスを呼び出す」ためのIAMロールのことを「Service-Linked Role」、「サービスにリンクされたロール」と言います。

マネジメントコンソール上から作る場合には、勝手に作成されるもの。
Terraformなどでリソースを作成した場合には、 aws_iam_service_linked_role で作成しておくのが良さそう。

noboru_inoboru_i

AWS Config
https://aws.amazon.com/jp/config/
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/config_configuration_recorder

AWS リソースの設定変更を継続的にモニタリングして記録できます。

CloudTrailと似ているが、
https://aws.amazon.com/jp/config/faq/

AWS Config は AWS CloudTrail とどのように連携しますか?

をみると、CloudTrailは「操作のログ」であり、AWS Configは「設定値スナップショットとそのモニタリング」と理解しました。

大量のマネージドルールがあり、それらをまとめた「適合パック」も大量にある。
ルールを設定しておくことで、違反したものの通知などが行える。

また、Configのダッシュボードより、特定のリソースに対する設定の履歴などを閲覧することができる。
(EC2インスタンスが、いつ削除されたのか?など)
参考
https://business.ntt-east.co.jp/content/cloudsolution/column-try-26.html

noboru_inoboru_i

AWS Budgets
https://aws.amazon.com/jp/aws-cost-management/aws-budgets/
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/budgets_budget
("Cost Management" の配下)

予算を設定しておいて、それを超えた(もしくは超えそう)な場合にアラートを発信できる。
昔は、CloudWatch Alermを利用していたようですが、専用のサービスができたようです。

EC2やS3などのリソース単位で予算を設定したり、カスタムの期間単位で設定できたりする。