概要
当エントリーでは、セキュリティグループIDが明確な場合に、当該セキュリティグループのルールに設定変更を加える手順について記載します。
セキュリティグループIDとは
Amazon Virtual Private Cloud (Amazon VPC) の仮想のファイアウォール相当の機能を有する セキュリティグループ を作成時に付与される一意のIDです。一意という事で、対象のセキュリティグループであるか否かを判断する上で有用です。
セキュリティグループIDは、接頭辞 sg- から始まる以下のようなイメージとなります (XXXは小英数字の乱数)
sg-XXXXXXXXXXXXXXX
(過去は乱数部が8桁でしたがAWSの普及に合わせ拡張されたという経緯があり、古くから利用しているAWS環境では桁数が少ないものと混在している場合があります)
セキュリティグループ=Security Group は頭文字をとって SG といったように呼ばれる事があります。
作業手順
今回はタイトル通り、セキュリティグループIDが明確な状態で、そのセキュリティグループに対して設定変更(ルールの追加/編集/削除)を行う手順について記載します。
(インバウンドルールの新規追加の場合は、セキュリティグループの開放といった表現がされる場合もあります)
前提
GUIのAWSマネジメントコンソール(言語設定:日本語)を利用しての設定変更手順とします
マネジメントコンソールの画面キャプチャは、執筆時点(202108)の内容となっており実際のものと異なる場合があります
対象セキュリティグループは、よくあるケースとしてインバウンドルールのみでIPv4で制御され、アウトバウンドはAWSのデフォルト(ALL許可) されているものとします
1.対象セキュリティグループの特定と現状の確認(全ケース共通)
(1-1).事前準備
AWSマネジメントコンソールに管理ユーザー(設定変更権限のあるIAMユーザー)にてログインします。
(1-2).対象リージョンへ移動
対象リソースのあるリージョンを選択します。
(補足) 当blogエントリーを閲覧される方の大抵は、東京リージョン= ap-northeast-1 をご利用かと思われます
(1-2).VPCサービス画面への遷移
画面上のサービス検索ウィンドウに「VPC」と入力し、 表示された[VPC]を押下します。
(サービス一覧からネットワーキングとコンテンツ配信にある VPCを押下でも構いません)
(1-3).セキュリティグループを押下
左ナビゲーションペインから セキュリティグループ を押下します。
(1-4). 対象セキュリティグループのフィルタリング(検索)
セキュリティグループ一覧画面に遷移するので、画面の上にフィルタリング用のウィンドウに対象セキュリティグループIDを入力します。
今回のサンプルでは、セキュリティグループIDが sg-0c0c704d25ddc4e5c とします。
(1-5). 対象セキュリティグループの詳細画面へ遷移
フィルタリング用のウィンドウに sg-0c0c704d25ddc4e5c と入力して実行し、対象のセキュリティグループが表示される事を確認します。
次に表示されたセキュリティグループのID が青文字のリンクとなっているので押下し、詳細画面に遷移します。
※もし、ここで対象セキュリティグループが表示されない場合は対象リージョンが異なる、または対象AWSアカウントが異なる可能性があるので確認してください
(1-6). 対象セキュリティグループ詳細画面にて現状の設定を確認
当該セキュリティグループの詳細画面が表示されるので、まずは現状の設定を確認します。
当サンプルでは、以下の様に読み取れます。
インバウンドルール、つまりはAWSリソースに対する方向のアクセスに適用されるルールとして 全て(0.0.0.0/0) のネットワークから HTTPS(TCP:443) 接続が許可されている(*1) 192.0.2.100/32 のIPアドレスから SMTP(TCP:25) 接続が許可されている(*2) 203.0.113.0/24 のネットワークから ICMP 通信が許可されている (*3) 198.51.100.0/24 のネットワークから SSH(TCP:22) 接続が許可されている
*1...全ての場合は、0.0.0.0/0 と指定します
*2...特定IPアドレスのみから許可する場合は、このようにネットワークCIDRを /32 と指定します
*3...ICMPにはポートが存在しませんので、マネジメントコンソール上では「すべて」といった特殊な表現となっています(厳密にはICMPの中でも細かく許可する内容を制御可能です)
現状の内容について確認し、 実施すべき編集内容が明確となった場合 は後続の設定変更作業へと進みます。
※もし本番環境であれば編集作業を行う前に、変更前の情報として画面キャプチャーを取得しておく事をオススメします
(1-7). セキュリティグループ編集画面への遷移
※ここから実際の編集作業となりますので環境によっては慎重に実施ください
[Edit Inbound rules] を押下します
後の手順はケース毎に以下手順2〜4の中から実施したい内容を対応してください。
2.ルールを新規追加する場合
新たに接続元やプロトコルに許可を加えたい場合等は、ルールを新規追加します。
FW(ファイアウォール)でいう穴あけを実施するようなイメージになります。
今回はサンプルとして、新たに 203.0.113.0/24 のネットワークから SSH(TCP:22)接続 を新たに許可する設定を加えてみます。
(2-1).ルールを追加
[ルールを追加] を押下します。
末尾に空のルールが1行追加されるので、こちらにルールを指定していきます。
指定出来るのは、以下項目となります。
| 項目 | 詳細 |
|---|---|
| タイプ | よく利用される内容がタイプとして整備されているので用途にあったものを指定します(詳細は補足情報参照) |
| プロトコル | TCP/UDP/ICMP 等の利用するプロトコルを指定する項目です。ただし、タイプを選択する事で自動入力される事がほとんどです |
| ポート範囲 | ポートの範囲を数値(0 ～ 65535)を指定する項目です |
| ソース | プルダウンから好ましいものを選択し、カスタムの場合は手動で送信元の ネットワークCIDR を指定する項目です(詳細は補足情報参照) |
| 説明 | ルールに関するコメントを付与出来る項目です |
(補足情報) タイプについて
タイプは上の画面のように よく利用されるものをAWSが事前に用意してくれている イメージとなり、例えば、タイプを SSHとプルダウンから選択するだけで、プロトコルとポート範囲が TCP:22 として自動的に入力される 便利機能です。
カスタムTCPを選択して手動で入力し設定する形でも問題ありませんが、タイプの項目として存在している場合は活用した方が作業品質は上がるので活用したいところです。
(補足情報) ソースについて
ソースはプルダウンから以下項目が選択できます。
| 項目 | 詳細 |
|---|---|
| カスタム | 自分でIPアドレス情報を手入力する場合に選択します。 |
| Anywhere-IPv4 | IPv4から全て許可する場合はこちらを選択します。選択すると自動的に 0.0.0.0/0 と入力されます |
| Anywhere-IPv6 | IPv6から全て許可する場合はこちらを選択します。選択すると自動的に ::/0 と入力されます |
| マイIP | 現在、マネジメントコンソールへ接続している端末が利用している Public IPアドレスが自動的に入力されます |
(補足情報) 説明について
「説明」項目について記載は任意となりますが、何の為のルールなのか 人間がわかりやすいようにコメントをつけておく事をオススメします。
例えば、一時的な切り分け用途の穴あけだったら tmp- という接頭辞をつけるだとか
実施日付を yyyymmdd として付与するだとか、複数の会社が操作するようなAWS環境であれば、
実施担当の社名を記載するだとか、管理する組織として方針を決めておくと良いでしょう。
(2-2).ルールを設定し、変更をプレビューする
今回のサンプルの対応のために、タイプを SSHと選択し (プロトコルとポート範囲は自動入力)
ソースをカスタムで 203.0.113.0/24 と指定します。
以下画面の通り、正しく指定ができたら [ルールを保存]を押下してすぐ反映も可能ですが、 [変更をプレビュー]を押下して、設定変更内容を事前に確認してから反映する事をオススメします。
(2-3).変更内容を確認後、反映する
変更内容が表示されるので内容に問題がない事をチェックしてから、[確認] を押下します。
もし、ここで想定外の差分 (値のミスや想定外のレコード)が表示された場合は [戻る] を押下し設定し直します。
(2-4).ルールが新規追加された事の確認
セキュリティグループ詳細画面へと遷移するので、先ほど追加したレコードが反映されている事を確認します。
以上で、セキュリティグループのルールを新規追加作業は完了です。
必要に応じて画面右上よりAWSマネジメントコンソールからログアウトしてください。
(2-5).ルール新規追加後の動作確認
指定した内容について意図通り通信できるかについて確認します。
今回のサンプルでは 203.0.113.0/24 のネットワークから SSH許可をしていますので、ソースIPアドレスが 203.0.113.0/24 の範囲内のものとなっているクライアントから当該セキュリティグループがアタッチされているAWSリソースに対し、SSHが可能となった事を確認します。
3.既存ルールを編集する場合
一時的な切り分けとして許可するIPアドレスの範囲を変更したり、接続元のIPアドレスが変更になった場合に更新したりと既存のルールの設定を変更する場合にこちらの対応を実施します。
今回はサンプルとして、pingの疎通確認の一時的な切り分けが必要になったとして、
203.0.113.0/24 からしか許可していない ICMP を 全てのネットワーク(0.0.0.0/0)から許可する形に変更してみます。
既に利用されている既存の設定に変更を加える訳なので、もし設定を誤ると通信に影響が出る場合がありますので慎重に行って下さい。
(3-1).既存ルールの編集
編集画面に遷移した時点で、既存のルールについても編集可能な状態となっていますので、変更したい既存ルールに対して変更を加えます。
今回のサンプルでは、ICMPのルールのソースを 203.0.113.0/24 -> 0.0.0.0/0 に変更し、[変更をプレビュー]を押下します。
(ソースを Anywhere- IPv4にしても カスタムで 0.0.0.0/0 と手入力しても問題ありません)
(3-2).内容確認後、反映する
変更内容が表示されるので内容に問題がない事をチェックし、[確認] を押下します。
もし、ここで想定外の差分 (値のミスや想定外のレコード)が表示された場合は [戻る] を押下し設定し直します。
(3-3).既存ルールが正しく変更された事の確認
セキュリティグループ詳細画面へと遷移するので、先ほど変更したルールの設定が正しく反映されている事を確認します。
以上で、セキュリティグループのルールの変更作業は完了です。 必要に応じて画面右上よりAWSマネジメントコンソールからログアウトしてください。
(3-4).設定変更後の動作確認
意図通り、変更した内容で通信できるかを確認します。
今回のサンプルでは 203.0.113.0/24 以外のネットワークからも ICMP疎通 (pingコマンド応答)が想定通り得られる事を確認します。 (セキュリティグループ以前の問題で応答が得られない場合もあるかもでしれませんが、それはそれで切り分け情報として活用します)
4. 既存ルールを削除する場合
既存ルール設定が不要となった場合は当該ルールを削除します。
削除なので当然、対象ルールを誤ると通信に影響がでますので慎重に行って下さい。
今回はサンプルとして、当該AWSリソースのサーバーで MTA(SMTP)の機能が廃止となり、不要なルールを削除する想定で記載します。
(4-1).既存ルールの削除
編集画面では、既存ルールの右側に[削除]ボタンが存在していますので 削除するには対象ルールの[削除]を押下するだけです。
今回は、SMTPのルール行の [削除] を押下します。
(4-2).変更をプレビューする
削除を実施したルールの行が消えた事を確認し、[変更をプレビュー]を押下します。
(4-3).内容確認後、反映する
変更内容が表示されるので内容に問題がない事をチェックし、[確認] を押下します。
もし、ここで想定外の差分 (値のミスや想定外のレコード)が表示された場合は [戻る] を押下し設定し直します。
(4-4).ルールが削除された事の確認
セキュリティグループ詳細画面へと遷移するので、先ほど削除したルールが反映されている(表示されない)事を確認します。
以上で、セキュリティグループのルール削除作業は完了です。
必要に応じて画面右上よりAWSマネジメントコンソールからログアウトしてください。
(4-5).ルール削除後の動作確認
意図通り、削除したルール内容で通信が出来なくなった事を確認します。
今回のサンプルでは 192.0.2.100/32 のIPアドレス(ホスト) から SMTP接続許可ルールを削除しましたので、192.0.2.100/32 のホストから 当該AWSリソースに対し、SMTP接続が出来なくなった事を確認します。
まとめ
対象セキュリティグループIDが明確な場合の ルールの追加/編集/削除 の手順について紹介しました。
以下情報が揃った状態であれば、当エントリーの手順を読み替える事で自由に設定変更が出来るようになったと思います。
- セキュリティグループID
- プロトコルとポート範囲 (もしくはタイプ)
- ソース
慣れてしまえば 5minもかからない程度のAWSの基本的な作業となりますが、セキュリティに関わる重要な設定となりますので、反映すべき設定内容の検討には必要な時間をきちんとかけて、実際のオペレーションは慎重に行いましょう。
