なるべく楽したい
AWSセキュリティ
Leaner Technologies Inc.
黒曜
(@kokuyouwind)
$ whoami
-
黒曜 / @kokuyouwind
-
名古屋在住
-
Leaner Technologies Inc. 所属
-
Railsエンジニア
-
Next.js とか AWS 周りも触ってる
We're Hiring!!!
AWS セキュリティ
なんかいろいろある
IAM
WAF
SSO
Config
Organization
GuardDuty
SecurityGroup
CloudTrail
SecurityHub
ControlTower
Inspector
🤔
何をどこまでやれば……？
ちゃんと安全に運用したうえで、
なるべく楽したい！
どうやって安全に楽をするか
-
AWSのベストプラクティスに従う
-
SecurityHub でセキュリティチェック
-
-
なるべく持ち物を減らし、ツールの既定に合わせる
-
Fargateを使い管理対象インスタンスを減らす
-
ネットワーク環境構築をCopilot CLIに任せる
-
-
アプリケーションレベルでもAWSサービスを活用する
-
典型的な攻撃はアプリ到達前にWAFで防ぐ
-
ECRコンテナスキャンで脆弱性をチェックする
-
…という話をしていきます
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
AWSでWebアプリを運用するとき、
攻撃されそうなポイントを考えてみる
ざっくりしたWebアプリ構成
攻撃ポイント1: AWSアカウント
攻撃ポイント2: ネットワーク
攻撃ポイント3: Webアプリ
攻撃ポイント4: データストア
このあたりは確実に対策が必要
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
AWSアカウントの初期設定は
ベストプラクティスに従うのが確実
SecurityHub で設定状況チェック
Leaner のセキュリティスコア
セキュリティスコア100%じゃないの？
-
リモートワークだと物理MFAデバイスのハードルが高い
-
ルート封印だけとはいえ、アカウント作るたびに
誰かがボトルネックになるのは避けたい -
今は1passwordの仮想デバイスでMFA設定している
-
-
重要度: 中 以下は個別に対応するか検討している
-
Copilot CLIで作ったリソースが引っかかっているのは
リスク低ければ対応を見送っている -
ログ系は全対応するとコストが嵩む
-
環境ごとにAWSアカウントを分ける
誤操作や悪用時のリスクを低減
Control Tower使わないの？
-
徐々に設定を増やしていく戦略にしたので未導入
-
SSOなど自分が未使用だったものは
まず個別に触れてから統合サービスを入れたかった -
新サービス用のAWSアカウント準備を優先したので
なるべく小さく対応したかった
-
-
次にAWSアカウント作る前には移行しておきたい
-
権限管理も現状は最低限の分類なので、
移行のタイミングで見直したい
-
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
VPCやセキュリティグループは
Copilot CLIに任せると安全かつ楽
Copilot CLIで構築した環境
Copilot CLI構築の良い点
-
VPCだけでなくALBやECSのセキュリティグループも
自動で作ってくれる-
ECSはALBからのアクセスしか受けつけない設定になる
-
-
ECS on Fargateになるので持ち物が減る
-
EC2のOSやミドルウェア更新を気にしなくて良くなる
-
copilot svc exec でsshライクな作業も可能
-
-
今ならApp Runnerだともっと持ち物を減らせる
-
WAF未対応など課題がありECSにしている
-
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
Webアプリのセキュリティ対策
-
AWS WAFを挟んで典型的な攻撃を到達前にブロック
-
基本的なManaged Ruleを適用
-
標準リクエストで引っかかってしまうエンドポイントは
個別に許可ルールを設定
-
-
ECRでコンテナイメージをスキャン
-
重大な脆弱性がないかだけ定期的にチェック
-
-
GitHub Dependabotでセキュリティアラート
-
VAddyで定期的に脆弱性検査テスト
AWS WAF の推奨設定
Waf Charmのブログ記事にある
導入推奨セットがわかりやすい
AWS WAF の実際の設定
AWS WAF のブロックサンプル
AWS WAF のブロック通知
Slack通知してFalse Positive なブロックがないかチェック
ECR Container Scan
コンテナイメージを Clair でスキャンした結果が見られる
Critical含めていっぱい出てない？
CVEは False Positive も結構出る
(DockerのFAQにも項目がある)
Docker ImageのCVEは推移が重要
イメージ検査を重視するなら拡張スキャンにすると良さそう
(ただしスキャン毎のコストがそこそこ掛かるようになる)
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
データストアのセキュリティ対策
-
基本的なことをちゃんとやる
-
RDSはパブリックアクセスを無効にする
-
RDSの接続元はセキュリティグループで絞る
-
S3は「パブリックアクセスをすべてブロック」にする
-
データの暗号化を有効にする
-
-
SecurityHubに従っていれば上記は設定されているはず
アジェンダ
-
セキュリティレイヤーの分類
-
AWSアカウントのセキュリティ
-
ネットワークのセキュリティ
-
Webアプリのセキュリティ
-
データストアのセキュリティ
-
まとめ
どうやって安全に楽をするか(Reprise)
-
AWSのベストプラクティスに従う
-
SecurityHub でセキュリティチェック
-
-
なるべく持ち物を減らし、ツールの既定に合わせる
-
Fargateを使い管理対象インスタンスを減らす
-
ネットワーク環境構築をCopilot CLIに任せる
-
-
アプリケーションレベルでもAWSサービスを活用する
-
典型的な攻撃はアプリ到達前にWAFで防ぐ
-
ECRコンテナスキャンで脆弱性をチェックする
-
なるべく楽したいAWSセキュリティ
By 黒曜
なるべく楽したいAWSセキュリティ
AWS Startup Communityの「スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜」で発表した資料です。 https://aws-startup-community.connpass.com/event/241721/
