ちょっと話題の記事

セキュリティグループのSSH全開放をAWS Configで自動修復したら3分くらいで直ったからみんな使ってほしい件

AWS Config Rulesが自動修復に対応したので、SSHを全開放したら自動修復するように設定してみました。これまではLambda等の仕組みを自分で作る必要がありましたが、今回からその必要がなくなりました。ぜひ活用しましょう。

臼田佳祐

2019.09.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さん、自動化してますか？(挨拶

先日AWS Config Rulesでコンプライアンスに非準拠となった時に自動修復ができるようになりました。

もともとはLambdaを経由して自動修復が可能でしたが、今回はConfig Rulesで違反を検知してそのままSSM Automationを実行できるのでよりスマートに、より適切になった感じです。詳細は下記をご確認下さい。

[アップデート] AWS Config Rule 非準拠リソースを自動修復する機能が追加になりました！

で、今回はこの機能を利用してSSHを0.0.0.0/0で全開放してしまったセキュリティグループを自動的に修復するという事をやってみました！

タイトルに結論を書きましたが、3分くらいで自動的に修復されましたのでぜひ活用してほしいです。

SSHを全開放することは万死に値するので、もうすべてのAWSユーザはこの設定をすればいいんじゃないですかね？

やってみた

順序としては以下のようになります。

Automation用IAM Role作成
Config Rules設定
SSH全開放のSecurityGroup作成
自動修復

Automation用IAM Role作成

まずはAutomationで利用するIAM Roleを作成していきます。今回のAutomationはAWS-DisablePublicAccessForSecurityGroupというドキュメントを利用しますが、文字通り全開放されているセキュリティグループを無効化します。

実態としては0.0.0.0/0や::/0となっているSSH(とRDP)を削除する動きになります。そのため、権限としてはec2:RevokeSecurityGroupIngressを与えることにより動作します。

IAM Policyにてこれを許可するポリシーを作成します。「ポリシーの作成」から実施します。ビジュアルエディタからの場合はサービスでEC2を選択して該当のアクションを許可します。

jsonとしては下記のようになるでしょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ec2:RevokeSecurityGroupIngress",
            "Resource": "*"
        }
    ]
}

その後、IAM Roleを作成します。上記で作成したポリシーを適用して作成完了します。作成したらRoleのARNを控えておきます。

作成時にはサービスでEC2を選択して作成しましたが、SSMから利用するロールのため「信頼関係」からec2.amazonaws.comをssm.amazonaws.comに変更します。

Config Rules設定

続いてSSH全開放を検知して自動修復するConfig Rulesを作成します。AWS Configのルール画面から「ルールの追加」を押します。

AWSでデフォルトで用意されているルールの中から「ssh」と入力して検索し、restricted-sshを選択します。

設定にて修復アクションとしてAWS-DisablePublicAccessForSecurityGroupを選択し、自動修復を「はい」にします。任意ですが、再試行回数がデフォルト5回になっていますが、あまり繰り返すことに意味のないアクションですので1回に変更してもいいでしょう。

続いてはAutomationに引き渡すパラメータの設定です。「リソースIDパラメータ」はConfig Rulesで検知したIDを渡す設定です。このRulesではセキュリティグループを検知するためSecurityGroupIDが「リソースIDパラメータ」で渡されます。今回のAutomationのドキュメントでは是正するセキュリティグループのIDをGroupIdキーで受け取りますので、「リソースIDパラメータ」でGroupIdを指定します。その他にこのドキュメントでは実行する際のIAM RoleをAutomationAssumeRoleで受け取るため、先程作成したIAM RoleのARNを入力します。設定したら「保存」を押して作成完了です。

SSH全開放のSecurityGroup作成

対象となるセキュリティグループを作成していきます。今回は他のルールは削除されないことを確認するため、SSH全開放のルールと、マイIPのルールを設定します。

作成できました。現段階ではSSHが全開放されています。

自動修復

しばらく待っているとConfig Rulesの作成したルールの詳細画面でアクションが実行されたことが確認できました。

実際にセキュリティグループを確認しに行くと全開放のルールが消えて/32のルールだけが残りました。想定どおりです。

CloudTrailのイベント履歴から「リソース名」にセキュリティグループIDを指定して調べると、リソースの作成から自動修復まで3分21秒で対応している事を確認できました。状況により時間差はあるかと思いますが、とても速い対応だと思います。

まとめ

これまでもConfig RulesでSSHの全開放を検知したり、それを見て手動で修復することはできました。もう少し頑張って、CloudWatch Eventsから自前のLambdaを呼び出して自動で修復することもできました。

しかしながらどちらも辛かったです。

今回はAWSが用意したRulesを利用して、AWSが用意したSSM Automationを組み合わせることで自動修復まですることができますので、ユーザ側で頑張る必要はありません。なんて素晴らしいのでしょうか！

これを機に、今回紹介したSSH全開放の自動修復を始め、AWSから提供されているConfig Rulesによる危ない設定の検知やAutomationによる自動修復を試してみてはいかがでしょうか？

最後に、オススメのConfig Rulesを下記で紹介しているので合わせてご参照ください。

Config Rulesが激安になるのでみんな使ったほうが良いRuleを紹介します！

セキュリティグループのSSH全開放をAWS Configで自動修復したら3分くらいで直ったからみんな使ってほしい件