Q&A
URLは https://teratail.com/help#about-markdown の[リンク]を使ってください。
当方初心者で、もし自分も請求されてしまったら恐ろしいと思いました。
AWSの公開キーとは、一体どういったものでしょうか？
secrets.ymlのファイルの、中にある長い暗号みたいなsecret_key_baseの事でしょうか？
そうならないための対処法などがあれば教えていただきたいです。
回答2件
0
AWSの公開キー
混ざってますよ
具体的には、どんなコードを書いてしまう事なのでしょうか。
普通にLinuxマシンを貸し出すEC2やデータベース・サーバーを貸し出すRDSを利用している分には一生関係ありませんが、AWSは自身の持っている様々なサービスと連携できるようになっています。
これらの連携前提のサービスはAWSのアカウント情報でやり取りしているので、
ファイアウォールやポート設定などといった普段サーバを立ち上げる際の煩わしい設定を無視して欲しいサービスを享受できるようになります。
例えばSQSのようなメッセージ・キューサービスですね。
誰でもいいからSQS上に仕事としてメッセージを投げておいて、バッチが巡回してきてメッセージに対して私が仕事しますという宣言を行います。
仕事が完了すればメッセージを解決扱いにして削除、完了出来ずにエラー落ちしたら数分で応答無しになってまた別のバッチに任せるという作りのサービスです。
その気になれば別にMySQLとバッチでも出来ますけど？？？…、まぁ、実装するのは結構大変ですよね。
特に仕事が完了出来ずにエラー落ちしたままになるレアケースへの対応。
こんな風に使いこなせば便利な機能がAWSには山のように詰まってて、
アカウント情報があればスクリプトやプログラムから自由にメッセージを投げて仕事を依頼できるんですね。
IAMというサービスを使えばこれらの情報を作成、管理できます。
ところがこのアカウント情報、どうやって本番環境へもっていくねんって所が悩みの種。
本Qiita記事のような知識の無いエンジニアに任せるとアカウント情報をGitHubで管理し始めます。
(Qiitaの記事執筆者さん、身をもって痛い思いをして勉強したので、もう同じヘマはやらかさないでしょう)
GitHubは基本的にソースコードを全世界に公開するというサービスですから、
アカウント情報をGitHubに上げてしまうのはアカウント情報を含めてどうぞご自由にお使いくださいと同義の非常識な行為です。
例えるなら貴方は銀行を経営しています。ガードマンを雇いました。ガードマンは巡回後に施錠して出ていきますが、鍵の束を玄関先にぶら下げて帰ります。もちろんこの鍵の束は銀行の前を通りがかった誰でも取って銀行内を自由に探索できます。
まじか、お金盗られるじゃん！おバカだ！！
はい、まさにそのとおり。
まぁ、大問題ですけど、
鍵が玄関先にかかってる程度なら良いんですよ、普通はガードマンに金庫まで行ける鍵を渡しませんから。
金庫にさえ通さななければ金は盗られませんからね。
このAWSのアカウント情報、IAMというサービスで払い出すのですが、
Aサービスにはアクセスできるが、Bサービスにはアクセス出来ないという条件設定が可能です。
上記の例ならば、SQSだけ利用するなら、SQSだけ許可にしたアカウントが生成できます。
つまり金庫を開けるような鍵はそもそも作らないんですよ、
ガードマンには巡回してほしい箇所の鍵だけ作って渡す。
なので仮にやらかしたとしてもそんなにダメージは大きくありません。
しかし、こういう横着な輩は全ての権限にアクセスできるマスターキーの合鍵1個で管理し始めます。
ガードマンも支配人もみーんなこのマスターキー1本。
しかもそれを玄関先にぶら下げます。そうすると泥棒が次々と侵入して金庫を漁っていきます。
この二重の怠慢が原因で悲劇がおこります。
AWSの場合はビットコインの採掘が殆どです。
費用対効果は非常に悪く、100万円かけて数万円分を採掘できるか怪しいくらいなのですが、他人の金で最強のマシンをボンボン建ててビットコインを採掘して持ち逃げする仕組みにしています。
まぁ、犯人にしてみれば他人の金で焼き肉を食べるようなもんです。
アクセスログを追えばどこに送金したかで犯人を捕まえられそうですが、犯人は似たような間抜けなアカウントを次々と乗っ取りバケツリレーのようにしてるでしょうから中々足がつかないと思います。
この辺の仕様はAWSにも問題があるんじゃないかなぁと思ってます。
- アクセスキーへの取り扱いへのアナウンスがゆるい
- IAMでのアカウント発行をもっと手軽に、セキュアな設定を作れるようにしてなさそう
これからも新人エンジニアが増えていきますから、
この辺をどうやって知ってて当然に持っていけるが社会全体の課題なのかもしれません。
結局アクセス情報はどうすればよかったのか？
- GitHubのプライベートリポジトリ
- 社内に鯖を建ててGitLabやGitHubEnterpriseなどで管理
- マシンを建てて環境変数で流し込む
- マシンを建ててコマンド実行時引数などで流し込む
- Configファイルなどは別口でSSH接続を利用してアップロード
前者2つはものぐさな人にオススメ
ただ、GitHubのプライベートリポジトリは毎月お金払って下さいと言われるので、
子会社が勝手に課金を辞めた結果パブリックリポジトリに切り替わり、公開したらあかんデータが公開されてしまって問題になったという間抜けな事件がありました。
社内にサーバーマシンでも建ててそこで頑張るのが良いのかもしれませんね。
マシン自体はクラウド上に置いて、IPアクセス制限を社内にかけるなどの管理方法もあります。
後者はソースコードにこういったクリティカルなデータは一切持たないという管理方法で、デプロイ時にスクリプトで一緒に流し込みます。
その場合、じゃあそのアクセスキーは誰が管理するねんという問題を後ろにずらしただけで、
結局社内のHDDに置いたり、S3なんかに置いたりという感じで頑張って管理する事になります。
どんな仕組みであれ不特定多数にこのアクセスキーを見せなければ問題ありません。
こんな感じで管理方法は色々とありますので、
調べてみたり、他のエンジニアと相談したりしてみてください。
投稿2018/10/15 05:47
編集2018/10/15 05:59
総合スコア21497
0
AWS のキーについては、AWS のアクセスで使うアクセスキーとシークレットキーのことですね。
git で、公開するのを予防する方法としては、
クラウド破産しないように git-secrets を使う
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した
などが、参考になるでしょうか。
投稿2018/10/14 22:25
総合スコア25234
あなたの回答
tips
プレビュー
