AWSの強い権限のクレデンシャル管理から転生した件

クレデンシャルをパスワードみたい使ってない？

　開発チームには最低限の権限付けたクレデンシャルを払い出し、その点ではセキュリティは確保しているものの、運用系には強い権限を持ち、かつトラブル対応時に期限が切れないように永続的な権限を払い出してはいないでしょうか。権限が強いので更新などを所有者に移譲しているため、定期更新なんかしないで使い続けてる管理になりがち・・

これではパスワードと何も変わらない！

このツールはAWSでのクレデンシャル管理の概念を変えるため作られました

作ったわ！

詳しくはリポジトリで。バイナリをダウンロードして即使いたいならこっち

v0.3

もっと安全に使えるような機能を三つ追加しました！

• IPアクセス許可機能
  • アクセスを許可するIPを指定出来るようになりました

こんなかんじで許可を書いて

$ ./goCred -proxy -port=8080 -allow=172.18.,172.19.,172.20.

そうじゃないIPからの接続はフィルターします！

Token error: error 192.168.0.1:51240: not allow!

• 不正アクセス検知機能
  • 上記の許可機能に該当しない、またはトークンの間違った接続をカウントして上限を越えたらブロックできるようになりました

カウント数を指定しています。

$ ./goCred -proxy -port=8080 -filterCount=3

以下の様にトークンがあっていない接続でブロックしたら、正しいトークンが来ても接続できなくなります

$ ./goCred -client -token=wrongToken 192.168.0.1:8080
OS: Linux
Token error: error token invalid
exit status 1
$ ./goCred -client -token=wrongToken 192.168.0.1:8080
OS: Linux
Token error: error 192.168.0.1:51150: over retrys
exit status 1
$ ./goCred -client -token=trueToken 192.168.0.1:8080
OS: Linux
Token error: error 192.168.0.1:51150: over retrys

• SALT機能対応
  • SALTを付けて暗号化する事でトークンが特定されないようになりました

有効化するには各モードで-saltオプションを有効化する必要があります

$ ./goCred -proxy -port=8080 -salt

$ ./goCred -server -token=test -salt 10.0.0.1:8080

$ ./goCred -client -token=test -salt 192.168.0.1:8080

どんなん？

このツールを使うと・・

• 強い権限を持つクレデンシャルを作らなくて済みます
• 更新期限を意識してクレデンシャルを運用しなくてすみます

えええええええええ！？！？

どういう事だってばよ！？

GitのArchitectureより

SSL & AES encrypted Credential by Token
_____________         __________         ___________
|Server mode | ----> |Proxy mode| <---- |Client mode|
-------------         ----------         -----------
|Cloudshell  |       Tokenized Data     SSL & Dencrypt by Token
-------------

このツールはだいぶトリッキーなAWSの仕組みを利用しています。
前提としてAWS CloudShellを起動し、以下を叩くと短期で強い権限のクレデンシャルが払い出されています。

curl -H"Authorization: $AWS_CONTAINER_AUTHORIZATION_TOKEN" $AWS_CONTAINER_CREDENTIALS_FULL_URI

このクレデンシャルを中継してクライアント側で使っちまおう！というのがこのツールの発想

動きとか分かんないと怖いんすけど、、、

• CloudShellとクレデンシャルを使いたい端末の両方からアクセス可能なネットワークでProxyモードでツールを起動させます。両方からのHTTPSアクセスを待ち続けます

• CloudShell上にこのツールをアップします(またはgitからダウンロードします)。ServerモードとしてProxyモードでツールが動いている端末に通信を開始します。この際、クレデンシャルはトークンを使い、AESで暗号化されるのでProxyに送られても生クレデンシャルは見えません

• クレデンシャルを使いたい端末からClientモードでProxyへアクセスします。この際にトークンを指定し、取得した文字列からクレデンシャルを複合します。複合できたらユーザープロファイル配下のクレデンシャルファイルを更新します

• CloudShellのクレデンシャルには期限があるので、期限が近づくとServerはProxyに新しいクレデンシャルを送り、ClientはProxyに向けて新しいクレデンシャルをリクエストします。これによりクレデンシャルは永続なのにも関わらず、中身は更新されていくのでセキュリティも強固になります。かつ、自動更新なのでユーザーは透過的に使用し続けられます

やったね！

は？CloudShellのブラウザはタイムアウトすんじゃん！

　ここがこのツールのミソで、超簡易的なRPAの機能を内包しています。そのため、CloudShellを開いているブラウザに定期的にキーボードでエンターを叩いたのと同じ操作を行います。これがあるのでブラウザはタイムアウトせずにCloudShellへのアクセスは途絶えません。テストで二時間は確認した。
(ただ、RPA的な動きなので現時点でWindowsでしかこれは機能しないです。。)

あとがき

CloudShellがVPCに接続できないのでちょっち怖いなと思うかもだけど

https://aws.amazon.com/jp/blogs/news/aws-cloudshell-command-line-access-to-aws-resources/

現在、セッションはプライベート VPC サブネット内のリソースに接続できませんが、近日中に接続できるようになる予定です。

　という事なのでこれが接続できるようになれば**社内VPCで完全に閉じたネットワークでクレデンシャルを作成しないで運用できるってことになるわけです！**そしたら、ちっこいWindowsインスタンスでこのツール動かしておけば強いクレデンシャル問題はマジで解決しそう・・