CDP:Operational Firewallパターン

From AWS-CloudDesignPattern
Jump to: navigation, search
Architect

機能別アクセス制限

Contents

解決したい課題

規模の大きいシステムになると、開発保守を行うための組織が複数存在するケースがある。例えば、システムを開発を行う会社、ログ解析や運用監視を行う会社などに分かれるケースなどが該当する。 ファイヤーウォールのルールを機能ごとのグループで定義した場合、ある組織にたいしてアクセス元が変更になったり、アクセス自体を不要にしたい場合には、都度、機能ごとにグループ化されたルールを変更する必要があるので設定に手間がかかる。また、それぞれの組織がどのサーバにアクセスができるのかを、一元的に管理することもできない。

クラウドでの解決/パターンの説明

従来、ファイアウォールは専用機器を利用し、ルールも機能ごとにまとめた形で記述(管理)することが多かった。 クラウドではファイアフォールに関しても仮想化されており、より柔軟に設定することが可能となっている。そしてルールをグループ化し、グループ単位での設定や各サーバへの適用を行うことができるものもある。 このグループの単位を組織ごとにすることで、組織に関する設定をグループ内で一元管理することができるようになる。そして、その組織のアクセスを不要にしたい場合は、グループを該当サーバに対して不適用にするだけで容易に実現することが可能となり、運用時の効率を高めることができる。

実装

AWSにはセキュリティグループと呼ばれる仮想ファイアウォールがあり、複数作成することも可能である。組織ごとにセキュリティーグループを作成することで、組織ごとのルールを一元管理することができ、組織単位でEC2への適用も可能となる。 VPCの場合は、動作中のEC2に対してもセキュリティグループを適用/不適用することができる。

  • 開発会社や運用会社などの組織ごとに、セキュリティグループを作成する。
  • 各セキュリティーグループに、グループ(組織)に応じた設定を行う(アクセス元やアクセスポートなど)
  • セキュリティグループを、適切なEC2に適用する

構造

6wNg0ISJczU5Pz1m-68E67.png

利点

  • アクセスしてくるセキュリティグループ(組織)ごとに、アクセス情報を一元管理できる
  • アクセス制限を変更する際に、設定のミスを低減できる
  • Functional Firewallと併用することも可能

注意点

  • セキュリティグループは通常ユーザの識別機能はなく、接続元IPアドレスを用いた制限がメインとなるため、ユーザごとの制御はOSやアプリケーションレイヤーでの実装が必要
  • VPCでないと、起動中のEC2に対して動的にセキュリティグループを適用することがができない。

その他

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox