AWS アカウントを守るために最低限やるべきこと

この記事を書いたメンバー:

那須 隆

AWS アカウントを守るために最低限やるべきこと

目次

やっと AWS のセキュリティについて少しずつわかってきました。那須です。
何度か AWS のセキュリティについて記事を書いてきましたが、最低限これだけはやったほうがいい内容についてもまとめておこうと思います。
すべて AWS のサービスを使うことで実現できます。
皆さんの環境と照らし合わせて一度確認してみてください。
(2020.01.20時点の情報です)

CloudTrail 有効化

AWS アカウントに対する API アクセスのログを保管できるサービスです。
何かあった時に、いつ誰が何をやったかを後から確認できるので重宝します。
また EventBridge で特定の操作があったタイミングで自動でアクションを起こすための元ネタにもなります。
正直 CloudTrail を有効化していないといろんな自動化の仕組みを作るのが大変なので、絶対有効化しましょう。
(2017年8月よりアカウント作成後に自動で有効化されているはずです)


AWS CloudTrail(ユーザーアクティビティと API 使用状況の追跡)| AWS

aws.amazon.com

og_img

Config 有効化

リソースの記録や変更履歴を残してくれます。
いつの時点でどのような構成だったのか、またそのリソースはいつ誰がどのように変更したのかを後で追うことができます。
またルールを設定することで、そのルールから外れた設定やリソースを作成されてもすぐに気づけます。


AWS Config(リソースのインベントリと変更の追跡)| AWS

aws.amazon.com

og_img

Route53 ログ設定

Route53 へのクエリログを保管します。
詳細は以下のドキュメントを見てください。
トラブルシューティングでも活躍するログなので収集しておきたいです。


docs.aws.amazon.com

GuardDuty 有効化

CloudTrail イベントログ、VPC フローログ、DNS ログの 3 つのログを分析して、悪意あるアクティビティを検出します。
セキュリティグループで 0.0.0.0/0 で ssh を許可した EC2 インスタンスを作成してからものの数時間でいろんなところから不正なアクセス試行が大量に検出された経験があります。
もし GuardDuty を有効化していなければそれに気づかずに「何も実害出てないから大丈夫♪」と余裕をかましていたことでしょう。


Amazon GuardDuty(マネージド型脅威検出サービス)| AWS

aws.amazon.com

og_img

CloudTrail イベントログ、VPC フローログ、DNS ログの 3 つをデータソースとしていますが、ユーザがこれらのデータソースを個別に設定する必要はありません。


よくある質問 - Amazon GuardDuty | AWS

aws.amazon.com

og_img

Security Hub 有効化

コンプライアンス状況の確認、およびセキュリティアラートを一元的に集約して確認できます。
GuardDuty、Inspector、IAM Access Analyzer、Firewall Manager 等のアラートを集約できます。
運用中はなるべく少ない画面で複数の要素を確認したいと思いますので、こちらも有効化して活用しましょう。
中でも、CIS AWS Foundations Benchmark で定義された項目は一通りチェックするようにしましょう。


AWS Security Hub(統合されたセキュリティ & コンプライアンスセンター)| AWS

aws.amazon.com

og_img

IAM Access Analyzer 有効化

外部アカウントと共有している IAM ユーザやロールを検出します。
自分たちのアカウント以外から利用できるようにしているが、意図しないアクセスがないかどうかを確認するのに役立ちます。


AWS Identity and Access Management Access Analyzer - Amazon Web Services

aws.amazon.com

og_img

セキュリティグループ(SG)の 0.0.0.0/0 の削除

EC2 インスタンスに 0.0.0.0/0 で許可していると本当にいろんな人がアクセスしようと頑張ってきます。
そして気がつけばログインされて不正に利用されてしまうことになります(経験談)
AWS Config で 0.0.0.0/0 が設定されないようルール作成しておきましょう。

一人ずつの IAM ユーザ

IAM ユーザは複数人で共有しないようにしましょう。
IAM ユーザごとのアクションは追えますが、そこから実際に誰がアクションをおこしたのかが追えません。
また、その IAM ユーザを使っていたメンバーが退職等で抜けたらパスワードを変えて再周知するなど運用する上でも面倒です。

Inspectorで脆弱性チェック

EC2 インスタンスで外部向けサービスを提供しているなら Inspector で定期的に脆弱性チェックしましょう。
チェックしてリスクが発見されたら、どのように対応するのか検討してセキュリティ向上に努めましょう。

さいごに

ここに書いた内容はあくまで一例です。
他にもあるかもしれませんし、環境によっては適用できないものもあるかもしれません。
大切なのは、そのサービスをお客様に安心して使っていただくためにどうすればいいかを考えて設計・実装・運用することだと思います。
1 つずつでも大丈夫です。
少しずつでもいいので、安心して利用できるサービスを作っていきましょう。

カテゴリー
タグ

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)