アクセス権を付けずにクラウドにガバナンスを利かせるツール作ってみた！

# 如何なる理由でもアクセス権を付けるとセキュリティリスクになる
エンプラ界隈だとセキュリティ製品とかでリモートからアクセス許可して調査を肩代わりするようなサービスにおいて、そもそもアクセス権を付ける事が許可されないなんて事がある。
セキュリティを守るためにはサービスの利便性が下がるとしても堅牢さを失われないように、ガードを下げない方に倒すという考え方です
正しいとは思う。でもマルチクラウド、マルチアカウント横断で使用状況を可視化してガバナンスや統制を利かせたいCCoEとかにとっては高い壁となる考え方でもあると思う。
アクセス権が無いから出来ない、だから、統制の構築を諦める。そんな合間にもどんどんとクラウドの利活用は進んでいってしまう。それで問題ないんだろうか・・・

# ぴこーん！ (閃きのセレンディピティ発現)
別件でアウトバウンドの通信は何でも許可してるけど、内向きは絶対NGだから堅牢っすーてなネットワーク構成図を見てて[ngrok](https://ngrok.com/)みたいなのが内から動かされたら、お外からアクセス許可出してないとか堅牢にならないじゃんね、とか思ってたら、

### あ、そうだ！アクセス権無くても、情報を送ってこさせれば良いんじゃね！？

ということを思いついた

# そこで作っちゃうのが何時もの僕で

[![yasutakatou/goVernance - GitHub](https://gh-card.dev/repos/yasutakatou/goVernance.svg)](https://github.com/yasutakatou/goVernance)

## v0.2

コンフィグに[forcealert]というモードを設定しました。
統制サイドがどんなアラート通知設定をするか、見られたくない情報を通知していまわないか心配な場合に、この設定をすると統制サイドのアラート通知コマンドを強制的に上書きするようになるモードです

```
[forcealert]
echo "force alert! : {}"
```

このようにコンフィグに書く事でアラート通知コマンドを上書きできます。{}にアクション名がはいります

# 何をしてくれるツールなの？

- 統制サイドは取得したいリソース情報をコマンドに落とし込んでS3なり共通のアクセス権を持たせた場所に実行コマンドを配置しておきます
- アカウント管理サイドはツールとEC2上やLambdaなんかで設定・構築し、コマンドで取得したいリソース情報の許可ポリシーをロールとして付与します。操作されたくないコマンドはツールのコンフィグにてフィルターします
- 定期的にツールを動作させる仕組みにさせ、実行ごとにリソースの差分をdiffコマンドっぽく比較します
- 差分が統制サイドにて設定した閾値を超えた場合、統制サイドへのアラートを通知するコマンドが実行されます

つまり、統制サイドとアカウント管理サイドの2種類にコンフィグを分ける事で

- 統制サイドは**取得したい情報を任意で設定できる**。差分アラートが起きたら知ることができる
- アカウント管理サイドは**アクセス権を付与せず、取得させなくないコマンドをフィルターしつつ、統制サイドに利用情報を通知できる**。また、**具体的なリソース名などは送らず、差分情報だけを提供するので情報も最小になって安全**

というセキュリティを守りながら統制を運用する仕組みを実現します！

# 動作イメージ

[Lambdaで動作させる場合](https://github.com/yasutakatou/goVernance#lambda-mode)をサンプルとして、S3の差分を統制監視する場合を掲載します

Lambdaでaws cliを組み込んだレイヤーを作成して、zipファイルのアップロード等で関数をデプロイします。アカウント管理側のコンフィグファイルをバイナリに同封してください。
こんなかんじに統制サイドのコンフィグの取得コマンド、許可するコマンド類をホワイトリストとして記載します

```
[input]
aws s3 cp s3://defines-s3-backet/define.ini /tmp/define.ini

[whitelist]
.*aws s3 ls.*
.*aws s3 cp s3://defines-s3-backet/define.ini.*
.*aws sns publish --topic-arn "arn:aws:sns:ap-northeast-1:128259705520:email".*

[blacklist]
.*aws ec2.*
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/df807914-35a3-4913-b397-2d8f12b1dce1.png)

環境変数に動作パラメータを渡します。コンフィグファイルの配置場所、シェルのパス、テンポラリファイルの配置場所を指定します
**Lambdaは/tmp/に配置されたファイルはウォームスタートの場合、永続的になり、再実行時に消えなくなります**

```
[define]
s3 list up	1	aws sns publish --topic-arn "arn:aws:sns:ap-northeast-1:128259705520:email" --message "s3 add > 1" --subject "s3 diff alert"

[s3 list up]
aws s3 ls
```

統制サイドはリソースを取得する定義、閾値、アラート通知用のコマンドを定義します。
下側でS3のリストを出力している部分は複数行書くことができ、**最後に実行したコマンドが比較対象になります**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/49945b32-3bc8-44e1-ad89-69bc957190ce.png)

新しくバケットを2つ作ってみます

```
Status: Succeeded
Test Event Name: test

Response:
"governance done!"

Function Logs:
START RequestId: 65b1723d-8fe1-4565-a3be-10d666e6b317 Version: $LATEST
command: aws s3 ls
2025-03-23 08:40:02 defines-s3-backet
2025-03-27 06:43:27 defines-s3-backet2
2025-03-27 06:43:35 defines-s3-backet3
-- diff -- 
2025-03-23 08:40:02 defines-s3-backet
-2025-03-27 06:43:27 defines-s3-backet2
-2025-03-27 06:43:35 defines-s3-backet3
-- -- -- 
Alert: aws sns publish --topic-arn "arn:aws:sns:ap-northeast-1:128259705520:email" --message "s3 add > 1" --subject "s3 diff alert"
command: aws sns publish --topic-arn "arn:aws:sns:ap-northeast-1:128259705520:email" --message "s3 add > 1" --subject "s3 diff alert"
{
"MessageId": "2d62a728-c0a5-5764-9304-c77636ae3d95"
}
END RequestId: 65b1723d-8fe1-4565-a3be-10d666e6b317
REPORT RequestId: 65b1723d-8fe1-4565-a3be-10d666e6b317	Duration: 26906.24 ms	Billed Duration: 26907 ms	Memory Size: 128 MB	Max Memory Used: 119 MB

Request ID: 65b1723d-8fe1-4565-a3be-10d666e6b317
```

差分が閾値の1を超えているので、アラート通知用のコマンドが実行されました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/7b2ece4f-1ac0-452b-9782-29bb3fc07d04.png)

SNSを通じて、メールにてアラートが通知されました

メール通知だけでも良いのですが、**組織横断的なダッシュボードとするため、Powerautomateなどのローコードツールを活用して、メールが来たらExcelなどに集計できる仕組みを構築するとより捗る**かと思います

(参考)
[PowerAutomate事例:メールの本文を抽出してエクセルに転記](https://unite-365.co.jp/powerautomate-mailtoexcel/)

## 注意事項
LambdaはEC2でツールを運用するより、セキュリティ的に堅牢で、手軽にスケジュール実行できますが取得するコマンドの実行時間によっては、**Lambdaの実行時間上限**にひっかかってしまうので、関数を分ける等の対処が必要となってきますので注意してください

# あとがき
AIコーディングが流行ってて、こんな400行未満のコードなんてAI使ったら速攻で出来る気がするけど、僕はN88Basicからコーディングに入った古い人間なのもあって、ついスクラッチで書いてしまう。
自分のアイデアが形になって、動いた時の快感が止められない。
OSSだし素人の日曜大工的なものなのでAI使わない、コーディングの楽しみを味わうって意味でスクラッチ勢も一定層残り続けそうな気がしている昨今です。