AWSのシステム運用に求められるセキュリティ要件

AWS のセキュリティ対策の重要性

AWS でシステム運用するうえで、セキュリティ対策は必要不可欠です。
AWS は「誰でも簡単に仮想サーバーをセットアップして利用できる」という大きなメリットがある反面、ちょっとした設定ミスや見落としによってサーバーが攻撃対象になってしまったり、機密データの漏えい事故が発生したり、さまざまなセキュリティリスクが潜んでいます。
AWS の分かりやすいメリットだけに目がいってしまいがちですが、上記のような運用中に発生するリスクを熟知してしっかりと対策する必要があります。

AWS の責任共有モデル

AWS のセキュリティ対策を考える前に、必ず理解しておかなくてはならない「責任共有モデル」という概念があります。
これは、AWS 上のインフラストラクチャのセキュリティについて、ユーザーと AWS のそれぞれがどの範囲で責任を担保するのかを明確に定義するためのものです。

AWS は公式ページで「責任共有モデル」について記載しており、ネットワークやサーバーなどの物理的な設備からハイパーバイザーまでの範囲を AWS が責任を持って管理し、それより上のレイヤーである OS やミドルウェアの設定、保存されているデータなどについてはユーザーが責任を持って管理する必要があると明記されています。

言い換えると、OS より上のレイヤー全てのセキュリティ対策はユーザー自身が責任を持って管理する必要があるのです。

EC2 を例に上げると、OS より上のレイヤーのセキュリティ対策には「セキュリティグループの設定」も含まれています。セキュリティグループは EC2 インスタンスの仮想ファイアウォールとして機能するもので、インバウンドトラフィックとアウトバウンドトラフィックを制御します。
セキュリティグループを適切に設定することで、EC2 インスタンスに対する攻撃や不正なアクセスを防ぐことができます。
もしも、セキュリティグループの設定が適切ではなかった場合、どのようなリスクが考えられるでしょうか。
例えば、システムのメンテナンス時に一時的にセキュリティグループの特定のポートを許可してメンテナンス後もそのままの状態になっていた場合、攻撃者に意図的に狙い撃ちされるリスクが大幅に増加します。

また、AWS には 各サービスやリソースに対してのアクセス権限を細かく設定することができる IAM (Identity and Access Management) という機能が用意されており、この機能の権限設定についてもユーザーが管理する必要があります。
例えば、協力会社に発行した IAM ユーザーに対して誤って管理者権限を割り当ててしまった場合、どのようなセキュリティ事故が予想できるでしょうか。
本来であれば見ることができないサーバーの情報を見られてしまったり、重要なデータが書き込まれている S3 オブジェクトをダウンロード出来てしまったり、本番環境にある EC2 インスタンスを削除することさえ簡単に出来てしまうのです。

AWS のセキュリティ対策

では、これらのセキュリティ事故を防ぐためにはどのような対策が必要でしょうか。

AWS には AWS Config という AWS リソースの設定を記録して評価するサービスがあり、ユーザーの AWS 環境のリソース状態が変化したタイミングで、対象のリソースが想定した通りの構成/設定になっているかどうかを確認できる仕組みを構築することできます。
「リソースが変化したタイミング」とは、例えばセキュリティグループに新しいルールが追加された場合もこれに当てはまります。
セキュリティグループに特定のポートを許可するルールが追加された場合に、マネージドルールと呼ばれる AWS 側で予め用意しているルールを実行するように設定することで、「許可する必要のないポートが許可された状態のままになっている」というようなセキュリティリスクを可視化し、外部からの攻撃を事前に防ぐことができます。

しかし、AWS が提供しているマネージドルールだけで全てのセキュリティリスクをカバー出来るわけではありません。マネージドルールではカバーできない AWS リソースの構成/設定を検査するには、カスタムルールと呼ばれるユーザーが独自で定義するルールをユーザー自身で用意する必要があります。

カスタムルールでは AWS リソースが変化したタイミングで、ユーザーが書いたコードを元に AWS Lambda
が実行されるようになっているため、対象リソースがルールに準拠しているのかを判定するロジックを含むコードをユーザー自身が準備する必要があり、実用レベルで使える状態にするためには一定以上の知識が求められます。
また、AWS Config ではルールに準拠していないリソースがあった場合に特定のユーザーに通知するといった設定も可能ですが、AWS Config 以外の他のサービスを組み合わせて設定する必要があり、この通知設定にも一定以上の AWS に関する知識が必要となります。

Cloud Automator で AWS リソースを定期的にチェックする

Cloud Automator の構成レビュー機能を活用すれば、あらかじめ用意されている「サーバーワークスが推奨する AWS を利用するうえで守られるべきポリシー」が詰まったテンプレートから必要なポリシーを選択するだけで、お客様の AWS リソースがルールに沿って運用されているかを定期的にレビューすることができます。
また、ルールに準拠していなかった場合の通知も複雑な設定を行う必要はなく、同機能の中で簡単に設定することができます。

この機能を利用することで、AWS に構築されたシステムがガイドラインに沿っていることを保証することができますし、ガイドラインに沿っていないリソースが見つかった場合には、必要な担当者に通知してガイドラインに沿った構成への変更を素早く行うことができます。

導入事例

こちらの導入事例は Cloud Automator を導入して、今回ご紹介した構成レビュー機能を活用されているお客様です。
合わせてご覧下さい。

• 導入事例: 株式会社IDOM様
• マネックス・セゾン・バンガード投資顧問株式会社様