広告(AdSense)

広告(Amazon)

AWS-チープなりなセキュリティとコンプラ その2 config編

2021年4月29日

金は無くとも、使い続ける以上やることはやっておきましょうということで急増テレワーク環境にまずはの管理を追加しておこうという趣旨です。

濃ゆい方針やルールはなくても利用しているリソースの状況の確認は必要なわけで「AWS Config 」から手を入れていこうと思います。
リソースの設定を評価、監査、審査する機能なわけで、セキュリティとコンプラを考える上では外せない機能です。
AWSだけではないと思いますが、クラウドサービスのいいところ「サービス」提供という点だと個人的には思ってます。
知識がある人が使えば、要件整理して設計して機能を使いこなして突き詰めていくという従来通りのインフラ運用のアプローチもできますが「サービス」である以上、あるあるな内容なパッケージ的に設定が用意されていて内容を見聞すれば「とりあえず選択して使おう」というアプローチも可能なわけですね。

AWS configも例に漏れず「AWS によって管理されるルールの追加」というものが用意されています。
「カスタムルールの作成」はどこまでいっても「Lambda 」がついて回るのでお手軽い始めるというわけにもいかんのでやはり誰でも使える「AWS によって管理されるルールの追加」最低限必要なものをピックアップというのが良いのだと思います。

そもそものconfigの役割ですが単純です。
利用しているリソースがルールを守って作成・運用されているかを管理・通知する
をしてくれる機能です。ざっくり言えば以下をやってくれます

  • 設定した追加に基づいてリソースの状態を確認
  • ルールに基づいて判定
  • ルール通りなら準拠、ルールに抵触した場合は非準拠として表示

設定すると実際、以下のように表示されます。

非準拠はルールで設定した停止継続期間を過ぎたEC2が検出された物です

実際にルールを設定するには、configのメニューからルールを選択します。
実際には適合パックというのもあるんですが、適合パックはルールとアクションまでをひとまとめにパッケージ化する機能です。アクションは事前にカスタムルール用のLambdaなども用意する必要があるので今回はスルーします。
いきなりやっても鼻血が出るし、バーターでやると実装優先でパッチワークだらけのヘンテコ方式クラウドができ上がる可能性大なので良くも悪くもスモールスタートが一番です。
非準拠のリソースを自動でどうこうするとか、大量に出力された通知を絞るとかしなければいけなくなったら考えることにしましょう。

ルールが登録されていると上記にように表示されます。

「ルールの追加」をクリックしルールを登録していきます。
とにかくお手軽にいこうという趣旨なので「AWSによって管理されるルールの追加」を選択し一覧から表示される一覧から選択していきます。

今回は以下を選択してみました。
とりあえず迂闊な公開がされていないか、長期間停止されているEC2がいないかを最低限見ることにします。

選択ルール内容
s3-bucket-public-write-prohibitedS3がパブリックの書き込みアクセスを許可していないかの確認
パブリックポリシー、ACLでパブリックの書き込みが許可されているS3は非準拠
s3-bucket-public-read-prohibitedS3がパブリックの読み込みアクセスを許可していないかの確認
パブリックポリシー、ACLでパブリックの読み込みが許可されているS3は非準拠
ec2-stopped-instance許可された日数を超えて停止したEC2インスタンスがあるかの確認
設定した日数以上停止したインスタンスは場合は非準拠
restricted-sshセキュリティグループに無制限のSSHのインバウンド通信許可以外が存在していないかの確認
(例えば 0.0.0.0/0 などの指定)
IPアドレス単位での許可以外のSSHのインバウンド通信許可があるセキュリティグループは非準拠
restricted-common-portsセキュリティグループにIPアドレス単位以外のTCPで無制限のインバウンド通信許可が存在指定ないかの確認
(例えば 0.0.0.0/0 などの指定)
IPアドレス単位での許可以外の設定したTCP通信のインバウンド通信許可があるセキュリティグループは非準拠

各ルールの設定

s3-bucket-public-write-prohibitedとs3-bucket-public-read-prohibited
詳細

名前デフォルトのまま
説明デフォルトのまま
管理されるルールの名前変更不可

トリガー

トリガータイプ変更不可
変更範囲リソース
リソースMultipsle SelectedのプルダウンからAWS S3 Bucketを選択(デフォルト)
頻度24時間(デフォルト)

パラメータは何もしない

ec2-stopped-instance
詳細

名前デフォルトのまま
説明デフォルトのまま
管理されるルールの名前変更不可

トリガー

トリガータイプ変更不可
頻度24時間(デフォルト)

パラメータ

キー
AllowedDays3
デフォルトは30日。ここでは3日以上停止しているEC2インスタンスが対象

restricted-ssh
詳細

名前デフォルトのまま
説明デフォルトのまま
管理されるルールの名前変更不可

トリガー

トリガータイプ変更不可
変更範囲リソース
リソースMultipsle SelectedのプルダウンからAWS EC2 SecurityGroupを選択(デフォルト)

パラメータは何もしない

restricted-common-ports
詳細

名前デフォルトのまま
説明デフォルトのまま
管理されるルールの名前変更不可

トリガー

トリガータイプ変更不可
変更範囲リソース
リソースMultipsle SelectedのプルダウンからAWS EC2 SecurityGroupを選択(デフォルト)

パラメータ

キー備考
blockedPort120FTPポート(制御)
blockedPort221FTPポート(コネクション)
blockedPort33389RDPポート
blockedPort43306DB利用ポート
blockedPort54333DB利用ポート
基本デフォルト。追加したい場合はblockedPortを連番で追加し、値にTCPポート番号を記載し追加

このように追加しておけば、最低限ズボラに開放されていたり放置したりされているリソースが非準拠として確認が可能になります。
AWSで用意されている管理ルールはここであげたものだけでなくかなり豊富です。小・中規模の仕組みであればそれなりに管理可能になります。
関わる人が多くなるとどうしても野良リソースや、あけっぴろげなお試しの後とか始末したいものですから。
※それようにちゃんと分離された砂場用意してもやる人はやりますんで・・・

まずは管理する側に回ったなら仕組みに慣れる、利用している側も無制限に使えるわけではないというケジメの線(見張ってるよ〜んの意識)の第一歩は必要ですから。