AWS-チープなりなセキュリティとコンプラ その2 config編
金は無くとも、使い続ける以上やることはやっておきましょうということで急増テレワーク環境にまずはの管理を追加しておこうという趣旨です。
濃ゆい方針やルールはなくても利用しているリソースの状況の確認は必要なわけで「AWS Config 」から手を入れていこうと思います。
リソースの設定を評価、監査、審査する機能なわけで、セキュリティとコンプラを考える上では外せない機能です。
AWSだけではないと思いますがクラウドサービスのいいところ「サービス」提供だという点にあると個人的には思ってます。
知識がある人が使えば、要件整理して設計して機能を使いこなして突き詰めていくという従来通りのインフラ運用のアプローチもできますが「サービス」である以上、あるあるな内容なパッケージ的に設定が用意されていて内容だけ見聞すればものは試しに「とりあえず選択して使おう」というアプローチも可能なわけですね。
AWS configも例に漏れず「AWS によって管理されるルールの追加」というものが用意されています。
「カスタムルールの作成」はどこまでいっても「Lambda 」がついて回るのでお手軽い始めるというわけにはいかんのでやはり誰でも使える「AWS によって管理されるルールの追加」から最低限必要なものをピックアップというのが良いと思います。
そもそものconfigの役割ですが単純です。
利用しているリソースがルールを守って作成・運用されているかを管理・通知する
をしてくれる機能です。ざっくり言えば以下をやってくれます
- 設定した追加に基づいてリソースの状態を確認
- ルールに基づいて判定
- ルール通りなら準拠、ルールに抵触した場合は非準拠として表示
設定すると実際、以下のように表示されます。
実際にルールを設定するには、configのメニューからルールを選択します。
実際には適合パックというのもあるんですが、適合パックはルールとアクションまでをひとまとめにパッケージ化する機能です。アクションは事前にカスタムルール用のLambdaなども用意する必要があるので今回はスルーします。
いきなりやっても鼻血が出るし、バーターでやると実装優先でパッチワークだらけのヘンテコ方式クラウドができ上がる可能性大なので良くも悪くもスモールスタートが一番です。
非準拠のリソースを自動でどうこうするとか、大量に出力された通知を絞るとかしなければいけなくなったら考えることにしましょう。
「ルールの追加」をクリックしルールを登録していきます。
とにかくお手軽にいこうという趣旨なので「AWSによって管理されるルールの追加」を選択し表示される一覧から選択していきます。
今回は以下を選択してみました。
とりあえず迂闊な公開がされていないか、長期間停止されているEC2がいないかを最低限見ることにします。
選択ルール | 内容 |
s3-bucket-public-write-prohibited | S3がパブリックの書き込みアクセスを許可していないかの確認 パブリックポリシー、ACLでパブリックの書き込みが許可されているS3は非準拠 |
s3-bucket-public-read-prohibited | S3がパブリックの読み込みアクセスを許可していないかの確認 パブリックポリシー、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時間(デフォルト) |
パラメータ
キー | 値 |
AllowedDays | 3 |
restricted-ssh
詳細
名前 | デフォルトのまま |
説明 | デフォルトのまま |
管理されるルールの名前 | 変更不可 |
トリガー
トリガータイプ | 変更不可 |
変更範囲 | リソース |
リソース | Multipsle SelectedのプルダウンからAWS EC2 SecurityGroupを選択(デフォルト) |
パラメータは何もしない
restricted-common-ports
詳細
名前 | デフォルトのまま |
説明 | デフォルトのまま |
管理されるルールの名前 | 変更不可 |
トリガー
トリガータイプ | 変更不可 |
変更範囲 | リソース |
リソース | Multipsle SelectedのプルダウンからAWS EC2 SecurityGroupを選択(デフォルト) |
パラメータ
キー | 値 | 備考 |
blockedPort1 | 20 | FTPポート(制御) |
blockedPort2 | 21 | FTPポート(コネクション) |
blockedPort3 | 3389 | RDPポート |
blockedPort4 | 3306 | DB利用ポート |
blockedPort5 | 4333 | DB利用ポート |
このように追加しておけば、最低限ズボラに開放されていたり放置したりされているリソースが非準拠として確認が可能になります。
AWSで用意されている管理ルールはここであげたものだけでなくかなり豊富です。小・中規模の仕組みであればそれなりに管理可能になります。
関わる人が多くなるとどうしても野良リソースや、あけっぴろげなお試しの後とか始末したいものですから。
※それようにちゃんと分離された砂場用意してもやる人はやりますんで・・・
まずは管理する側に回ったなら仕組みに慣れる、利用している側も無制限に使えるわけではないというケジメの線(見張ってるよ〜んの意識)の第一歩は必要ですから。
ディスカッション
コメント一覧
まだ、コメントがありません