CDP:Operational Firewallパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

機能別アクセス制限

目次

解決したい課題

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

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

 従来、ファイアウォールは専用機器を利用し、ルールも機能ごとにまとめて記述(管理)することが多かった。クラウドではファイアフォールは仮想化されており、より柔軟に設定可能である。ルールをグループ化し、グループ単位で設定したりサーバーに適用したりできる。このグループという単位をシステムにアクセスできる組織などにすることで、非機能要件的なアクセス制限に関する設定を使いやすく分割/一元管理することができる。

 他に非機能要件的なアクセス制限には下記のようなものを挙げることができる。[関連ブログ 1]

  • SSH/LDAPなどのログイン関係
  • 監視・バックアッップ
  • 管理コンソールへのアクセス
  • NTP・DNSなどの基本機能
  • メンテナンス時(パッケージのインストールなど)のHTTP(S)アクセス

実装

 セキュリティグループは複数作成できるので、組織ごとに作成し、組織ごとのルールを一元管理する。VPC(仮想プライベートクラウド)の場合は、動作中のEC2に対しても仮想ファイアウォールを適用/不適用を設定できるため、必要に応じて付け外しを行う事が出来る。

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

構造

6wNg0ISJczU5Pz1m-68E67.png

利点

  • アクセスしてくる組織ごとに、アクセス情報を一元管理できる。
  • アクセス制限を変更する際、設定ミスを低減できる。
  • Functional Firewallパターンと併用することも可能。

注意点

  • 仮想ファイアウォールは通常ユーザーの識別機能はなく、接続元IPアドレスを用いた制限がメインとなる。そのため、ユーザーごとの制御はOSやアプリケーションレイヤーでの実装が必要。

その他

関連ブログ

  1. suz-lab - blog の「"Operational Firewallパターン"をオレオレ解釈してCloudFormationのテンプレートにしてみた」( http://blog.suz-lab.com/2012/12/operational-firewallcloudformation.html )
個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス