自分はセキュリティエンジニアではないので最低限の話になってきますが、
普段の業務をしていてもやっぱりセキュリティとかヒューマンエラーの防止策って
本当に大事だなーと思います。
開発するにしてもアクセス権限は最低限にしておこうとか普段から意識してますが
プロジェクト内でセキュリティ意識が認識合わせできていないので個人の裁量に
任せたままになっていることが多い気がします。
クラウドセキュリティに必要なセキュリティ観点
防御
まず第一に攻撃の初期段階における外部との接続点を介した攻撃を防ぐ必要があります。
インターネットを経由した不正アクセスや不正ログイン、
侵入できたとしても暗号化によってリソースの不正利用の防止をするよう設定します。
主に次のようなサービス等を利用して防ぎます。
対応策 | AWSにおける該当機能 | 内容説明 |
---|---|---|
ルートユーザーの不使用 | IAM | 強力な権限をもつルートユーザーで作業せず、ユーザーアカウントを別途作成する。作業時はスイッチロールしてプロジェクト内の全てのユーザーが統一された権限で作業するのがベスト。 |
MFAの使用 | IAM | MFAデバイスを登録し、ログイン時にコードを入力する。ログイン情報が漏れた時の保険。 |
アクセスキー、シークレットキーの削除 | IAM | プログラムにアクセスキーとシークレットキーを保管しない。プログラムから取得する場合はSecret Managerに保管して取得するなどの対応を取る。 |
操作の制限 | IAM | ポリシーによるユーザーやリソースの操作制御を最低限に設定する。 |
通信相手の制限 | EC2、API Gateway | EC2はアクセスを許可したIPアドレス、ポート番号の制限をSecurity Groupで設定する。サブネット単位での制御はネットワークACLで制御する。API GatewayはAPIキー、リソースポリシー、相互TSL認証、Lambdaオーソライザー、Cognito認証、IAM認証等でAPIの利用者を制御する。 |
通信の暗号化 | AWS Certificate Manager | 通信の暗号化(HTTPS)を行う。 |
通信相手の認証 | Cognito | ユーザープールによるSSO機能の実装を行う。 |
ゾーニング | VPC | サブネットの分割によるネットワークから接続できる範囲の制限 |
データの暗号化 | S3、DynamoDB、Systems Manager、Secrets Manager等 | 外部からデータが読めないように暗号化する。Secrets managerはDBのパスワードを自動でローテンションも可能。 |
検知
次に攻撃が実施されてしまった後にすばやく管理者が検知できる仕組みを作ります。
検知ができることでその後の対応を素早く行うことができます。
BIツールと連携してグラフ化を行ったり特定の操作が行われたときにメールやSlackに
通知する仕組みを作成することもできます。
対応策 | AWSにおける該当機能 | 内容説明 |
---|---|---|
異常検知 | Amazon CloudWatch | 他のAWSサービスと連携してログを出力させる。アラートの設定も可能。 |
死活監視 | Amazon CloudWatch | メトリクスでEC2のCPU使用率などの監視を行う。 |
内部不正検知 | AWS CloudTrail | AWSサービスへの操作履歴をログに残す。 |