More Related Content
What's hot (19)
Viewers also liked (20)
Similar to ネットワーク構成から考える AWS IaaS 管理 (20)
![[Black Belt Online Seminar] AWS上でのログ管理](https://cdn.slidesharecdn.com/ss_thumbnails/aws-log-mgmt-161201043056-thumbnail.jpg?width=560&fit=bounds)
More from Hideaki Aoyagi (16)
Recently uploaded (8)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
ネットワーク構成から考える AWS IaaS 管理
- 2. 自己紹介 青柳 英明 職業： インフラSE (オンプレOnly) ?Visual Basic、ASP など (C#も Javaも Pythonも Rubyも出来ません…) 経歴： アプリケーション開発 … 3年 インフラエンジニア … 15年 ?サーバ/クライアント (Windows中心) ?セキュリティ系とかも少々 ?オンプレ仮想化 (VMware、Hyper-V) ?現在はデスクトップ仮想化をやってます AWS歴： 3ヶ月 趣味の範囲のみ 実務では全くやってません(やりたい) 前回の 「JAWS-UG 福岡 勉強会#2」 から 参加させてもらっています。 どうぞよろしくお願いします！
- 3. はじめに JAWS-UG の勉強会で、こういう話から始めるのも恐縮ですが??? 先日、マイクロソフトの 「de:code 2016」 に行ってきました。 聴講したセッションの一つ： 「Azure でのセキュアネットワーキング」 【内容】 ? Azure IaaS サービスにおける、セキュアなネットワーク設計のポイントの解説 ? サブネット分割の考え方 ? ネットワークセキュリティグループ(NSG) … VMに適用するステートフルなファイアウォール規則 ? ユーザ定義ルート (UDR) … サブネット間のルーティング定義 ? ネットワークACL etc.
- 4. はじめに JAWS-UG の勉強会で、こういう話から始めるのも恐縮ですが??? 先日、マイクロソフトの 「de:code 2016」 に行ってきました。 聴講したセッションの一つ： 「Azure でのセキュアネットワーキング」 ↓ さっそく Azure で実践してみよう！ ↓ どうせなら AWS でやってみて、JAWS-UG のネタにしよう！(笑) ↓ え？ AWS 界隈では 「クラウドデザインパターン (CDP)」 というチョー有名なものが？！ ↓ ええい！ 後には退けん！ とりあえずやってみよう！！
- 5. Subnet-Front Subnet-Back ① 最もシンプルな構成 VPC Web Server DB Server 一般利用者 管理者?開発者 Internet gateway SSH HTTP(S) HTTP(S) SSH SSH SQL Public IP Public IP Private IP
- 6. Subnet-Front Subnet-Back ① 最もシンプルな構成 VPC Web Server DB Server 一般利用者 Internet gateway Public IP Public IPSSH HTTP(S) HTTP(S) SSH SSH SQL Private IP SQL 10.0.0.0/16 SSH XX.XX.XX.XX/32 セキュリティグループ (Inbound) HTTP(S) 0.0.0.0/0 SSH XX.XX.XX.XX/32 セキュリティグループ (Inbound) (グローバルIPアドレス：XX.XX.XX.XX) (10.0.0.0/16) 特定アドレスに限定しているとは言え、 DBサーバ(バックエンド)に対してインターネットからの直接着信を許可しているのは怖い… 10.0.0.0/16 local 0.0.0.0/0 IGW ルートテーブル 管理者?開発者 10.0.0.0/16 local 0.0.0.0/0 IGW ルートテーブル
- 7. Subnet-Front Subnet-Back Subnet-Management ② 管理用ネットワークと「踏み台マシン」の導入 Web Server DB Server 一般利用者 Bastion (踏み台) Internet gateway HTTP(S) HTTP(S) SQL SSH SSH SSH SSH VPC 管理者?開発者 Public IP Public IP Private IP Private IP
- 8. Subnet-Front Subnet-Back Subnet-Management ② 管理用ネットワークと「踏み台マシン」の導入 Web Server DB Server 一般利用者 Bastion (踏み台) Internet gateway Public IP Public IP HTTP(S) HTTP(S) SQL SSH SSH SSH SSH SQL 10.0.0.0/16 SSH 10.0.0.0/16 セキュリティグループ (Inbound) HTTP(S) 0.0.0.0/0 SSH 10.0.0.0/16 セキュリティグループ (Inbound) SSH XX.XX.XX.XX/32 セキュリティグループ (Inbound) (グローバルIPアドレス：XX.XX.XX.XX) (10.0.0.0/16) Private IP Private IP VPC 管理者?開発者 10.0.0.0/16 local 0.0.0.0/0 IGW ルートテーブル 10.0.0.0/16 local 0.0.0.0/0 IGW ルートテーブル 10.0.0.0/16 local 0.0.0.0/0 IGW ルートテーブル
- 9. Subnet-Front Subnet-Back Subnet-Management ③ 本番ネットワークと管理用ネットワークを分離 VPC ピア接続 VPC：Production Web Server DB Server 一般利用者 Bastion (踏み台) Internet gateway Internet gateway HTTP(S) HTTP(S) SQL SSH SSH SSH SSH Public IP Public IP 管理者?開発者 VPC：Management 用途の異なるネットワークを明示的に分離し、 必要な通信のみを行わせる Private IP Private IP
- 10. Subnet-Front Subnet-Back Subnet-Management ③ 本番ネットワークと管理用ネットワークを分離 VPC ピア接続 VPC：Production Web Server DB Server 一般利用者 Bastion (踏み台) Internet gateway Internet gateway HTTP(S) HTTP(S) SQL SSH SSH SSH SSH Public IP Public IP 管理者?開発者 VPC：Management ? サブネットに対して適用する ステートレスなファイアウォール 用途の異なるネットワークを明示的に分離し、 必要な通信のみを行わせる ネットワーク ACL Private IP Private IP
- 11. ③ 本番ネットワークと管理用ネットワークを分離 ルール# タイプ プロトコル ポート範囲 送信元 許可/拒否 100 SSH (22) TCP (6) 22 xx.xx.xx.xx/32 許可 110 カスタム TCP ルール TCP (6) 32768-60999 10.0.0.0/16 許可 * すべてのトラフィック すべて すべて 0.0.0.0/0 拒否 ルール# タイプ プロトコル ポート範囲 送信先 許可/拒否 100 SSH (22) TCP (6) 22 10.0.0.0/16 許可 110 カスタム TCP ルール TCP (6) 32768-60999 xx.xx.xx.xx/32 許可 * すべてのトラフィック すべて すべて 0.0.0.0/0 拒否 インバウンド ルール アウトバウンド ルール 10.0.0.0/16 10.200.0.0/16 xx.xx.xx.xx ネットワーク ACL の定義
- 12. Subnet-Front Subnet-Back Subnet-Management ④ VPN の導入 VPC：Production VPC：Management Web Server DB Server 一般利用者 Bastion (踏み台) Internet gateway VPN gateway customer gateway (VPN ルーター) Public IPHTTP(S) HTTP(S) SQL SSH SSH SSH SSH 管理者?開発者 VPC ピア接続 インターネットから直接着信する 唯一のエンドポイント 管理用ネットワーク ＝ 社内ネットワークの延長 → 管理用ネットワークのセキュリティには十分留意する Private IP Private IP Private IP オンプレミス
- 13. Ａシステム 管理ネットワーク 「Aシステム」 管理者?開発者 踏み台 マシン Ｂシステム Ｃシステム 「Bシステム」 管理者?開発者 「Cシステム」 管理者?開発者 オンプレミス クラウド管理者 管理
- 14. 管理用ネットワーク導入のメリット ? アクセス経路が一本化、かつ、必ず 「踏み台マシン」 を経由することになるため、 利用ログの記録や、不正アクセスの検知などが行い易くなる。 ? 「踏み台マシン」 を停止することにより、完全にアクセスを遮断することができる。 必要な時のみ 「踏み台マシン」 を起動する運用を行うことで、セキュリティを高められる。 ＜応用例＞ ? スケジュールジョブにより起動?停止を自動化する (夜間の不正利用を防止) ? 「踏み台マシン」 の利用を申請による許可制にする → いずれも、運用の即時性?柔軟性が損なわれるという諸刃の剣になりますが… ? 外部からの砦となる 「踏み台マシン」 は徹底的にセキュアにすることが求められるが、 サービスやモジュールを最低限に絞ったり、パッチ適用のために再起動を行うことなどが容易である。 (WebサーバやDBサーバでそれを行おうとすると??? 大変ですよね)
- 15. 最後に ? 今回、管理用ネットワークは 「踏み台」 用途に着目しましたが、 他にも 「監視」 や 「アップデートサーバ?レポジトリ等の配置」 などの利用方法が考えられます。 ? IaaS のセキュリティ対策としては、ネットワーク構成によるもの以外にも - マルウェア対策 - IPS/IDS、WAF などによる防御 - ID管理 - ログ監視、分析 など、複数軸からの対策が重要だと考えますので、 今後は、AWS におけるこれらのセキュリティ対策についても調べたいと思います。 ? 今回は時間の都合から 「踏み台を利用した SSH の多段接続」 の具体的な手法や、 Windows の場合の手法 (RDゲートウェイなど) について十分に調べることができませんでした。
- 16. ご清聴、ありがとうございました
Editor's Notes
- #2: 0:00 ～ 0:15 (15秒)
- #3: 0:15 ～ 1:30 (1分15秒)
- #4: 1:30 ～ 2:00 (30秒)
- #5: 2:00 ～ 3:00 (1分)
- #6: 3:00 ～ 4:00 (1分) 最初に、最もシンプルな、いわゆる「Web2階層モデル」の構成を考えてみます。 こんな感じで、利用者はインターネットからWebサーバへアクセス、WebサーバはDBサーバへアクセスします。 また、 [Click] 管理者は、クラウドですから、インターネットから入って行って、各サーバを管理します。 [Click] Webサーバへのアクセスは、利用者も管理者もパブリックIPアドレスでアクセスします。 一方、DBサーバへのアクセスは、WebサーバからはプライベートIPアドレスでアクセスしますが、管理者はパブリックIPアドレスでアクセスすることになります。
- #7: 4:00 ～ 5:00 (1分) ネットワークに関する設定ですが、まず、インターネットとの接点を設けるために、各サブネットへルートテーブルを設定します。 1行目はデフォルトでエントリされているものです。 2行目にインターネットゲートウェイへのルーティングを追加します。 [Click] 次に、仮想マシンに対してセキュリティグループを設定して、アクセスを制限します。 Webサーバは、インターネットの不特定多数のアドレスからHTTP(S)のアクセスを許可し、SSHは管理者のIPアドレスからのみアクセスできるようにします。 DBサーバは、VPC内部からのみSQLのアクセスを許可します。SSHはWebサーバと同様です。 [Click] 一般的な構成ではあるのですが、バックエンドに対してインターネットからの直接着信を許しているところが、オンプレのインフラ屋からすると違和感を感じます。
- #8: 5:00 ～ 5:30 (30秒) この構成を拡張して、管理用ネットワークを追加してみます。 [Click] 管理用ネットワークには踏み台となる仮想マシンを1台立てます。ちなみに英語圏では「Bastion(バスチャン、バスティオン)」と言うそうですが、「砦」という意味だそうです。 WebサーバとDBサーバへのSSH接続は、この踏み台マシンを介して行います。 [Click] 最初の構成と違うのは、WebサーバとDBサーバへのSSH接続がプライベートIPアドレスになるというところです。
- #9: 5:30 ～ 6:00 (30秒) ちょっとごちゃごちゃとしていますが、ルートテーブルとセキュリティグループの設定はこのようになります。 ルートテーブルのポイントは、DBサーバのいるバックエンドサブネットがインターネットと通信する必要がなくなるということです。 セキュリティグループの方は、WebサーバとDBサーバのSSH接続が、VPC内部からのみのアクセスに限定されます。
- #10: 6:00 ～ 6:30 (30秒) 次のステップとして、WebサーバとDBサーバがいる本番ネットワークと、管理用ネットワークの分離を行います。 全体の構成は、あまり変わらないように見えますが、前のステップでは VPC が1つだったのが、2つの VCP に分かれたのが大きな違いです。 「VPC ピア接続」 を作成して VPC と VPC を接続します。 [Click] これによって、用途の異なるネットワークを明示的に分離することができます。
- #11: 6:30 ～ 7:00 (30秒) ネットワーク間で必要な通信のみを行わせるために、ネットワークACLを設定します。 ネットワークACLというのは、いわゆるファイアウォールのようなものなのですが、セキュリティグループとは考え方や挙動が異なるため、ちょっと気をつける必要があります。
- #12: 7:00 ～ 8:00 (1分) ネットワークACLの具体的な設定は、このようになります。 インバウンドは、管理者のグローバルIPアドレス xx.xx.xx.xx からのSSH通信のみを許可します。 アウトバウンドは、本番ネットワーク 10.0.0.0/16 へのSSH通信のみを許可します。 加えて、ネットワークACLはステートレスな動作であるため、戻りのパケットについても許可をしなければなりません。 Linuxでは、戻りのパケットが使用するポート、これを「エフェメラルポート」と言いますが、このポートの範囲が 32768 から 60999 と決まっていますので、このように設定します。
- #13: 8:00 ～ 9:00 (1分) 最後のステップでは、いよいよ VPN を導入します。 全体的な構成はステップ③のままで、管理者からのアクセス経路を VPN でトンネリングします。 VPN の終端ですが、AWS 側は「VPNゲートウェイ」を作成して管理用ネットワークへアタッチします。 オンプレミス側は、VPNルータなどの機器を導入して、AWS と接続するための設定を行います。 [Click] この構成によって、インターネットから直接着信するポイントが、Webサーバのみになりました。 今までお話しした4つのステップは、1よりも2、2よりも3、3よりも4、とステップが進むにつれて、よりセキュアになりましたが、このステップ④については1点留意すべき点があります。 [Click] それは、VPN を導入したことにより、管理用ネットワークが社内ネットワークの延長という位置付けになるということです。 ですので、前のスライドでご説明した 「ネットワークACL」 の設定などが重要になってきます。
- #14: 9:00 ～ 9:30 (30秒) 次の絵は、これは実際に構築はしていないので妄想の域に留まるのですが、 応用パターンとして、複数のシステムで共通の管理ネットワークを利用して管理するというシナリオです。 [Click] 各システムの管理者?開発者は、管理ネットワークの踏み台を利用する権限は持っていますが、管理する権限は持っていません。 [Click] 踏み台の管理は、クラウド全体の管理者が行うことになります。
- #15: 9:30 ～ 10:30 (1分)
- #16: 10:30 ～ 11:30 (1分)