こんにちは、櫻井です。
セキュリティーグループでSSHを不必要に全解放（0.0.0.0/0）している場合、悪意のあるユーザからサーバにアクセスされてしまうリスクが増加してしまいます。「SSHを全開放しないように」ということを周知したとしても、人が操作している以上は間違いが起こる可能性があるため、フールプルーフ化させよう。ということが今回の目的です。
そのために、AWS ConfigでセキュリティーグループでSSHが全開放されていないかを監視するルールを作成します。作成されたルールで非準拠だった場合、Systems Manager オートメーションで全開放されているSSHを削除するという仕組みを作成します。
※セキュリティーグループのルールに追加されているHTTPポート及び、全解放ではないSSHは等は削除されません。
目次
手順
早速ですが、全解放のSSHを自動修正する手順をご紹介します。
AWS Config のセットアップを行う
AWS Configを利用している方はセットアップは終わっていると思うので、こちらの手順はスキップしてください
AWS マネジメントコンソールからAWS Configに移動し、”1-Click セットアップ”をクリックします。
細かい内容はAWS 側で設定してくれているので “確認” をクリックしてセットアップを完了します。
Config ルールを作成する
先程のセットアップが完了すると、ページが自動的にダッシュボードに遷移します。左側のタブの”ルール” を選択し、”ルールの追加” をクリックします。
“ルールタイプの選択” で “AWS によって管理されるルールの追加” を選択し、”AWS マネージド型ルール” で “restricted-ssh” を選択し “次へ” をクリックします。
こちらは、デフォルトで選択されているものを変更せずに “次へ” をクリックします。
設定が間違っていないことを確認したら “ルールを追加” をクリックします。
Systems Manager オートメーション用のIAMロールを作成する
Systems Manager オートメーションが、セキュリティーグループに対して変更を行うことができるようにするためのIAMポリシーをアタッチしたIAMロールを作成します。
このIAMロールをSystems Manager にアタッチすることで、Systems Manager は先程作成したConfigルールに準拠していないセキュリティーグループのインバウンドルールを削除する権限を得ることが出来ます。
IAMロールにアタッチするポリシーを作成する
IAMに移動し”ポリシーの作成” をクリックします。
JSONタブをクリックし、以下のポリシーを貼り付け “次へ” をクリックします。
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ec2:RevokeSecurityGroupIngress", "Resource": "*" } ] } |
任意の名前をつけ “ポリシーの作成” をクリックします。
IAMロールを作成する
先ほど作成したIAMポリシーがアタッチされたIAMロールを作成します。
IAMで “ロールを作成” をクリックします。
“信頼されたエンティティタイプ” で “AWS のサービス” を選択し “ユースケース” で “Systems Manager” を選択して “次へ” をクリックします。
先ほど作成したIAMポリシーを選択し “次へ” をクリックします。
設定に間違いがなければ “ロールを作成” をクリックします。
作成したものは後ほど使うので、今作成したIAMロールのARNを控えておいてください。
自動修復の設定をする
再度Configに移動します。先ほど作成したルールを選択し “アクション” から “修復の管理” をクリックしてください。
“修復方法を選択” で “自動修復” を選択し “修復のアクションの詳細” は
“AWS-DisablePublicAccessForSecurityGroup”
を選択します。
“リソースIDパラメータ” に “GroupId” を選択し “AutmationAssumeRole” に先ほど控えたIAMロールのARNを入力して “変更を保存” をクリックしてください。
これでSSHが全開放されている場合は、自動で全開放されているSSHのみを削除する設定が完了しました。では、実際に動作の確認をしてみます。
動作確認
EC2に移動し、左側のタブから “セキュリティーグループ” を選択し “セキュリティーグループを作成” をクリックします
“ルールの追加” をクリックし”SSH” と”HTTP” を全解放（0.0.0.0/0）で作成します。HTTPについては、セキュリティーグループに登録されている全てのルールに対しての削除が行われないかの確認をするためのものです。Configが正常に動作した場合、SSHだけが削除され、HTTPは削除されないという結果になるはずです。
Configに移動し、先程作成したルールをクリックします。
“対象範囲内のリソース” を確認すると、先ほど作成したセキュリティーグループが非準拠になっていることがわかります。
何度かブラウザを更新すると “ステータス” の欄に “アクションが正常に実行されました” と出力されています。
その後、更に何度かブラウザを更新すると “評価結果がありません” となりました。
これでSSHの全解放のみが削除されているはずなので確認してみます。再度EC2に移動し、セキュリティーグループから先ほど作成したセキュリティーグループを確認します。
しっかりSSHだけが削除され、HTTPは残りました。
まとめ
以上でSSHが全開放されたセキュリティーグループのルールのみを自動で削除することができるようになりました。
これで、間違えてSSHを全開放してしまったセキュリティーグループのルールを作成してしまった場合も安心できます。
マルチアカウントで運用している場合、このようなセキュリティーに関する仕組みはCloudFormationなどのIaCを使ったデプロイをすることで、確実かつ楽に行うことができるので、後日CloudFormationを使った方法についても紹介する予定です。
一緒に働く仲間を募集中！
ギークフィードではAWSエンジニアを募集しています。
興味がある方はこちらからエントリーをしてぜひ一緒に働きましょう！
- 特定の時間あたりのlambda実行数をSlackに通知する - 2023-12-23
- 公衆電話からでも使える電話帳サービスをLEX + AmazonConnectで作ってみた - 2023-12-19
- SQSを使ってlambdaを10秒ごとに定期実行する - 2023-12-14
- Slack と AWS の電話番号登録アプリ – Bolt + CDK ソースコード解説 - 2023-03-26
- SlackとAWSを組み合わせた電話番号登録アプリの開発 – Boltフレームワーク+CDKで作ってみた - 2023-03-26
【採用情報】一緒に働く仲間を募集しています
