More Related Content Similar to Iret tech labo_14 (20) Editor's Notes まずは自己紹介させてください。
名前が小石倉広樹と言います。
2019年に新卒としてiretに入社いたしました。
仕事は開発エンジニアとしてAPIの開発を主にやっております。最近はちょくちょくNuxtを触ることも出てきました。
大好物はビールです。特に伊勢角谷さんのビールが好きです。八重洲と新宿にお店があるのでよかったら行ってみてください。W
好きなサービスはAPI GatewayとLambdaです。 はい。では早速やっていきましょう！アジェンダはこちらとなっております。
クレデンシャル情報をパブリックリポジトリに載せちゃう
lambdaのランタイムに入ってるAWS SDKと最新のSDKのバージョンが違う
CodeCommitで差分がでない
developブランチをマージする時に間違えて消しちゃう
の四本立てです！
もうすでに共感してくださってる方が中にはいらっしゃるんじゃないでしょうか！！ まずはこちらです。 これ、知ってる方も多いんじゃないでしょうか。 Twitterとかでたまにネタにされてますよねww はい。まずはクレデンシャル情報とはなんぞや。と言うところなのですが、
仮に皆さんが、クラウドにアプリをデプロイして、そこで動かすサービスを開発してる最中とします。
そのアプリはAWSで動かすとしましょう。 で、そのアプリはEC2と呼ばれる仮想サーバーで動かし ファイルストレージサービスのS3からファイルを取得する必要があると。 ただ、この時S3が情報を全員に公開するような設定になっていなくて、
特定のアクセス元のみに情報を渡す設定になってると、リクエストを送ってきた元が誰かわからず、君誰ですか？となってしまい、情報がもらえなくなっちゃうと言う事が起こります。 そこで例のクレデンシャル情報を使います。
具体的にはクレデンシャル情報のアクセスキーというものとシークレットアクセスキーというものを使います。 それを使うことによってS3は誰からリクエストが来たかを判定することができ、
情報を渡すことができるようになると言ったものです。S3が情報これです〜と言って渡してますね。
ただ言い換えると、このクレデンシャル情報が悪意ある人に渡ってしまうとリクエスト元を詐称することができ、
クレデンシャル情報に与えられた権限の中でなんでもできてしまうことになってしまいます。
S3にだけ権限が絞られていればまだ、S3だけで被害が収まりますが、これがrootアカウント、つまり一番強い権限を持ったアカウントのクレデンシャル情報だと大変なことになってしまいます。
世界中のリージョンにEC2を建てられたりして請求額がえらいことになります。
実際それをやらかして120万円請求された人もいたとか。。少し前にQiitaに記事上がって有名になりましたよね。あれがちょうど公開された頃確か自分は新卒で入ったばっかりで震えた記憶があります。 じゃあどうやってクレデンシャル情報が漏れちゃうか、ですが
この二つが多いと思われます。その中でも一番上が漏れてから悪用されるまでが一番早いので一番注意しなければなりません。
というのも不確かな情報ではありますが、Githubなどの公開リポジトリを運営しているサービスにクレデンシャル情報がないかどうか悪意あるユーザーがクロールしているらしいです。
もちろん悪用するために。。
ただ、AWS公式もGithubをクロールしていてクレデンシャル情報が漏れたアカウントに対して警告してくれているって情報もあったりします。。
まあただそうなってからでは遅いですよね。。 じゃあ対処法は？というとこちらです。
ここでミソなのがこれらのどれが欠けても完璧ではない、ということです。
一番上のGit SecretsというのはGitのcommit/commit message等の中身を調べて、その中に事前設定した秘密情報が含まれていたら、そのcommitをさせない仕組みです。
ここに書かれている以外でもSecret ManagerやSSMを駆使してそもそもアプリ上に絶対クレデンシャル情報を書かないと言った方法もありますが、コストもかかりますので
それらを使用しない場合はここに書かれていることを厳守する必要があります。 続きましてこちらです。これ意外にびっくりされた方いらっしゃるんじゃないでしょうか
自分も最初聞いた時にとても衝撃を受けました。 まあまずは見ていただきましょう。
こちらは普通にSDKのバージョンをまずは普通に出すだけのlambda関数を作り、実行したものです。
左がソースで右が実行結果です
バージョンが1.18.55と出ますね じゃあ最新バージョンは幾つなんだろというとこですが、本家サイト見に行くとどうやら1.20.7っぽいです。
マイナーバージョン2つ分も違うことになりますね。。
じゃあこれによって何が引き起こるかというと、言わずもがなですが、ドキュメント見て書いたのに動かない！！とかなったりしますね。 じゃあどうすれば良いかと言うと、Lambda Layerを使います。
ここではあまり深く解説しませんが、簡単に言うと複数のLambda関数同士でライブラリを共有できる仕組みと思っていただけると。。 じゃあ実際に使ってみます。
まずはSDKをダウンロードしてきます Zip化します そしたら新しいレイヤーを作成し、そこに先ほどzip化したSDKをアップロード そしたら新しいレイヤーを追加してやると。 先ほどと同じソースで実行するとバージョンが1.20.7になったことがわかりました。 続きましてこちらです。これわりと遭遇された方多いんじゃないでしょうか。 CodeCommitを使ってると
“違いを表示できません。個別のファイルが大きすぎて表示できないか、ファイル間の全体的な違いが複雑すぎます”と言う警告と共に差分がでないことがあります。
しかもめっちゃ大きなファイルでもないのに。。 そう言う時はもしかすると全角大文字が半角英数字の文字列の中に紛れてたりする事があります。
以外にそれを消すだけで洗われたりします。 最後はこちらです。これも意外な落とし穴ですよね。 ちょっと読みますね。
想像してください。
あなたはとても優秀な開発エンジニアです。
とても長い期間を経てある機能を開発し、
プルリクに来る辛辣な指摘コメントにも耐え、developブランチへのマージを
もぎ取りました。動作確認もし、いよいよリリースの時です。
リリースと言っても、優秀なCICDが備わっているので
やることはmainブランチに対して
プルリクを介してマージするだけです。 あなたはちゃんと宛先が間違っていないか何度も確認し、意を決して右下のマージボタンを押しました！
CICDが走り、production環境へデプロイが走ります！
デプロイが問題なく終わり、動作確認もできました！完璧かと思われましたが、ふと他のエンジニアが言います あれ？Developブランチなくね？ ギャー！と言うわけでなんでこんなことになったんでしょうか。 先ほどの画面、よくよく見返すとしたに
マージ後にソースブランチdevelopを削除しますか？とあります。そうなんです。Codecommitをプルリクでマージする時にデフォルトでブランチを削除する設定になっているんです。 対処法としては書いてある通りでIAMでdevelopブランチを削除できないようにできるのでその設定を行うようにします。 以上で発表を終わります。ご清聴ありがとうございました。
