AWS アカウントを横断して SSH ポート全開放を検知・修復する仕組みを導入した話

はじめに

こんにちは、IT 基盤部ネットワークグループの尾留川です。普段は、DeNA グループ全体のネットワークの管理、運用等を行っています。

今回は、社内全ての AWS アカウントのセキュリティグループにおいて、 SSH(TCP/22) ポートの全開放を検知し、ルールの自動削除を行うような仕組みを導入したので、ご紹介します。

導入の背景

社内で利用している AWS アカウントの総数は約 300 程度あり、これらのアカウントで SSH ポートの全開放を人の手で検知、対応することは困難でした。

元々、社内では Public IP を持つインスタンスに対して、一定時間毎にインターネット経由で SSH を試行し、SSH ポートが外部に開放されていないかを検知する仕組みが存在していましたが、以下のような問題点がありました。

インスタンスの数が膨大なため、 SSH の試行に時間を要する
開放検知後、アカウント利用者に連絡し、対応が行われるため、結果として多少の時間 SSH ポートが全開放されている時間が生じ、セキュリティリスクが発生してしまう

上記の問題を解決するために、セキュリティグループのルールを監視し、 SSH ポート全開放のルールが作成された時点で自動的にルールを削除するような仕組みを導入することとなりました。

まず思いついた方法は、AWS Config のマネージドルールである restricted-ssh を利用して SSH ポートの全開放を検知し、非準拠となったリソースに対して修復アクションを用いることで、セキュリティグループのルールを削除することでした。

この方法が一番容易なのですが、要件として例外的に SSH ポート全開放を許容するケースが存在し、修復アクションを用いる場合ではこのケースに対応できなかったため、別の案を考えることとなりました。

結果として、まず前述の restricted-ssh を社内の各 AWS アカウントに導入しました。そして、 SSH ポート全開放の検知を EventBridge を通じて1つの管理 AWS アカウントに集約し、管理アカウント上の lambda から検知したアカウントのセキュリティグループルールを削除することとしました。例外の管理は lambda で行っています。

続いて、具体的な仕組みについて紹介します。

SSH ポート開放検知システムの仕組み

まず、今回導入した仕組みの構成図は以下となります。

構成は、管理アカウントとターゲットアカウントの2つに大きく別れており、ターゲットアカウントは監視対象の社内全ての AWS アカウントを意味します。

ターゲットアカウントの動作

ターゲットアカウントの AWS Config では restricted-ssh というマネージドルールを有効化しています。このルールでは、セキュリティグループの受信 SSH トラフィックの IP アドレスが制限されているかどうか(0.0.0.0/0 が指定されていないか)を評価します。

restricted-ssh のルールが非準拠であることを検知した場合、そのイベントを EventBridge を経由して、管理アカウントの Event Bus に送信します。この時の EventBridge Rule のイベントパターンは以下のようになります。

{
  "source": ["aws.config"],
  "detail-type": ["Config Configuration Item Change"],
  "detail": {
    "messageType": ["ConfigurationItemChangeNotification"],
    "configurationItem": {
      "configuration": {
        "configRuleList": {
          "configRuleName": ["Restricted-SSH"],
          "complianceType": ["NON_COMPLIANT"]
        }
      }
    }
  }
}

管理アカウントの動作

管理アカウントでは、ターゲットアカウントから送られてくる SSH ポート全開放検知のイベントを元に、 lambda から対象アカウントのセキュリティグループ内の該当ルールを削除します。この時の EventBridge Rule はターゲットアカウントと同様のものを指定し、イベント検知時に lambda が発火するような設定となっています。

構成図中の lambda の部分の詳細を示したものが以下となります。

図中の system-asset とは、社内のクラウドアカウントを管理する内製アプリケーションで、開放検知時の連絡先を取得する際に利用しています。社内の AWS アカウントは TGW を介して接続を行っており、 VPC 内に配置した lambda と system-asset が TGW 経由で内部通信を行います。

そして、lambda で処理を行う際に、スプレッドシートを用いて例外アカウントの管理を行っています。例外アカウントを追加する際は除外期限を設定し、期限が切れたものに対しては自動的にルールの削除を行うような運用を行っています。

実際に SSH ポート全開放を検知した場合は、 3~5 分以内に、ルールの削除、通知が利用者に行われており、目的であるセキュリティリスクの軽減が達成できています。

構成管理

この SSH ポート開放検知の仕組みは、社内で AWS アカウント新規作成時にデフォルトで有効化されるものとなっています。そして、リソースの構成管理の監視を導入しているため、非意図的にリソースに変更が加えられた場合も検知し、修正できるような仕組みが導入されています。

また、今回導入したこの仕組みは、現状東京リージョンのみで動作させています。これは、2021/10/13 現在で東京リージョンの EventBridge がクロスリージョンでのイベントの受信に対応していないためです。 US East, US West, Europe リージョンではクロスリージョンでのイベント受信に対応しているため、今後東京リージョンもサポートされた際はクロスリージョンで動作するよう改修予定です。当初から上記のリージョン内に lambda を配置するという案もあったのですが、 TGW を新設する必要がある点や、他リージョンの利用は相対的に多くないという点から、まずは東京リージョンへの導入となりました。