Developers.IO 2017セッション「AWS Security Best Practices Whitepaperをガッツリ読み解く会」で話しました #cmdevio2017

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「AWS Security Best Practices Whitepaperをガッツリ読み解く会」を発表しました。そのレポートです。

発表スライド

セッション概要

セッションの内容はAWSでのセキュリティ対策について公式に発行しているAWS Security Best Practices Whitepaperの内容を改めて確認しようというものでした。
ある程度抽象的な内容が書かれていますので、参加者の皆さんの会社ではどのような対応をしているのか、という議論の時間も少しとらせて頂きました。

大まかな流れはスライドを見ていただくとして、セッション内容を録音していたので議論の内容をブログではまとめようと思います。

議論内容

スライドの中で「議論ポイント」となっている部分が今回議論したポイントです。
あくまでも一例で、正解があるわけではありません。

最低限の権限を与える

Q. ベストプラクティスとして「ユーザに最低限の権限を与える」というものがある。 理想は分かるが、実際にこれをやるとポリシーの運用にコストが掛かったり、構築・開発への影響（やりたいことが出来ないなど）がでたりなど弊害が出る。
なるべく弊害をなくしてセキュアにする運用をどうするか。

A1. 開発は緩く設定する。
IAMのアクセスアドバイザーなどで使用している権限を確認し、本番にはそちらだけ付与する。

A2. 基本的にマネージドポリシーを使用する。（新機能にも自動的に追従できる）
拒否したい機能だけカスタムポリシーで拒否設定を行う。

A3. 権限をガチガチにするより、何か問題が発生した際にすぐに検知できたり、対処できる仕組みづくり（出来れば自動で）のほうがAWSに即しているのでは。

複数のAWSアカウントを使用する

Q. 複数案件でAWSを使用している場合、AWSアカウントを分ける？分ける場合はどのように分ける？

A1. 基本的にPJ別にアカウントを分けている。本番・開発などでは分けていない。

A2. 一つのアカウントに複数PJあったり、1PJだけだったりする。
最近は1PJに1アカウントにするようにしている。
AWSアカウントを分けると、このリソースにはアクセスさせたくないというのが簡単。（単純にアカウントが違うので触れない）

A3. 分けるとコストの最適化（リザーブドインスタンス周りが特に）などが大変になる。
全アカウントをまとめた傾向を掴みづらい。
最近は、クロスアカウントで情報を集める仕組みなども提供されてきているのでやりやすくなってきた。

ここで、追加で質問がありました。

Q. ルートアカウントはどうしてる？

A1. MFAつけて一部の人間しか触れなくしている

A2. 古いスマホでMFA登録して金庫に入れている（物理的に入れないようにする）

セキュリティグループとNACLの使い分け

Q. セキュリティグループとNACL両方で管理している人はいます？

A1. 両方で管理していたが、辛かった。

A2. NACLは全サーバで適用したい拒否ルールだけ入れる。
例えば、攻撃者のIPや絶対に使わないポート（Linuxサーバしか無いのにRDPポートは要らない）など

まとめ

さすが公式に発行されたWhitepaperで改めて読んで非常に勉強になりました。
AWSを使えばセキュリティの責任範囲を減らし、色々なサービスを使ってセキュリティ運用の手間を減らすことが出来ますのでうまく使って楽に安全な環境構築をしましょう！