githubから自動pullする際のセキュリティ

Question

#前提、やりたいこと

githubのマスターブランチにプッシュされたら
github上のwebhookが発動し
レンタルサーバ内（Xserver）のphpを実行して
自動的にpullするという仕組みを構築しています。

以下のページがわかりやすく参考にさせていただきました。
https://yosiakatsuki.net/blog/github-auto-deploy/

動作自体はほぼ想定通りの動作をしていますが
セキュリティに関して疑問が出てしまった状況です。

#疑問点
2つ疑問点があります。

１つ目は自動pullをするphpファイルの置き場所
パーミッションについて悩んでいる状態です。

要件としてはできるだけセキュアにしたいと考えています。

現状wordpressなので
Username/public_html/wp-content/githubに配置して
動作させることはできました。
Username/public_html/wp-content/github直下にした理由は
・wordpressのコアアップデートの影響を受けない。
・Xserverで初期に割り当てられるUsername/scriptというディレクトリは
基本的にいじるところではないとサポートの方に教えていただいた。
ということを考えて配置しました。

githubディレクトリには参考ページ同様
ベーシック認証をかけております。

2つ目はXserverがpullする際のsshキーについてです。
参考ページにあります通りの手順で
Xserver内にssh接続した状態で以下のコマンドを実行しました。

ssh-keygen -t rsa

その結果
~/.ssh/id_rsa
というファイルがある状態で
.sshは700、id_rsaは600というパーミッションです。
プライベートキーがリモートサーバ（本番環境）にある状態だと思いますが
これはリスクがあるのではないでしょうか。

このような状態で運用した際に、自分には見えていないリスクがあれば
突っ込んでいただきたく質問をさせていただきました。

またもっといい方法がありましたら
そちらもご教授いただければ幸いです。
よろしくお願いいたします。

Answer 1

プライベートキーがリモートサーバ（本番環境）にある状態だと思いますが

これはリスクがあるのではないでしょうか。

例えば、なんですか？
「よくわからないから聞いてるんだろう！」って？
ネットワーク関係の正しい知識を身に着けてくださいとしか言いようがないです。

まぁ、原則として2つの事を気をつけていれば問題ありません。

• 秘密鍵は不特定多数に見られない事
• 秘密鍵が流出したとしても、GitHubに紐付けられているアカウントの権限を限定すること

---

ssh-keygenは秘密鍵、公開鍵の2つのファイルを作るだけの単なるコマンドです。
秘密鍵は流出しないようにパソコン内に保持、公開鍵はSSH接続先のサーバ等に公開して、
秘密鍵を使ったSSH認証で「あ、このアカウントの人だ」という事を覚え込ませる作りになっています。

例えばGitHubで使おうと思ったら、GitHubに本番環境用のアカウントを作成してそのアカウントの設定画面で公開鍵を保存します。
すると、Gitコマンドのssh接続モードを使って接続した時にIDやパスワードの情報が無くても秘密鍵で一意なアカウントが定まります。

もし秘密鍵のファイルが流出したら、GitHubにアクセスして公開鍵の設定を取り除けば問題はありません。
その後またssh-keygenコマンドで新しい秘密鍵と公開鍵のセットを作り直してください。

秘密鍵が流出した場合ですが、悪意の第三者が秘密鍵を利用してそのマシンになりすますことが可能です。
GitHubならPull、Push等が該当することでしょう。
で、質問者さんが本番環境のマシンでやりたい事ってなんですか？Pullだけですよね？Pushはしませんよね？
GitHubで作ったプロジェクトは、プロジェクト参加者にPullは出来るけど、Pushはできませんよといった権限を個別に設定できます。

正しい権限の設定がされている場合、もし本番環境の秘密鍵が流出したとしても、
Pushを禁止していれば悪意の第三者は何も悪さはできません。
精々Pullしまくってファイルを持ち逃げする程度です。
その内に気がついたタイミングで秘密鍵と公開鍵は破棄してしまえば良いのです。

このように2段構えで対策しておけば何も怖い所はありません。
正しい知識を身に着けて、正しく運用しましょう。

---

秘密鍵の流出の仕方

色々あります

• ssh認証が破られた: 色々と手遅れです。まぁプロジェクトのファイルを改ざんされる事はありませんが…
• Xサーバーの運用担当者がこっそりアクセスして盗んだ: 大事件です、もしそれが世間に知られれば誰もそのサービスを使わず会社が大きく傾くことになるでしょう。でかい信用問題になるので、Xサーバのような大手のサービスならばそこそこ安心だと思います
• Apache等で秘密鍵を全世界へ配布してた: バカ代表乙、質問者さんはちゃんと.ssh/id_rsaですし、パーミッションも適切で万が一にもこの路線で流出することはないでしょう
• ApacheやPHPのセキュリティホールで任意コマンドが実行出来るようになっており、バックドアを仕掛けられて抜かれていた: これが一般的な負けパターンです。特にphpMyAdminなどは超弱いので絶対に本番環境へ置かないようにしましょう。
• 御社内の別の担当者による内部犯: 脆弱性を突かれて突破以外ではこの内部犯がほぼ100%です。

怖いならセキュリティをチェックしてくれる会社やサービスがありますので、
予算の都合がつけば聞いて見るのも良いと思います。

Comments

[ruuusaamarki]

コメントありがとうございます。

漠然とした質問となってしまい申し訳ありません。
原則の２点、参考にさせていただきます。
githubのアカウントに関しては、自分の中でまだすこし
整理がついておらず質問するのも危ういレベルなので勉強します。
一応github上でmasterブランチへのマージには制限をかけました。

具体的な事例も大変参考になりました。
３と４は怖いですね。定期的に環境を見直す時間を
ワークフローに入れておかないと怖い気がしてきました。

他の原因も常にアナログ部分も意識しないとと改めて思いました。
貴重な知識ありがとうございました。

Answer 2

セキュリティは結構コストがかかるので、バランスをどうとるのか悩ましいところかと思いますが、できるだけセキュアとのことであれば、専門家に相談するのが一番かと思います。

１つ目は自動pullをするphpファイルの置き場所

パーミッションについて悩んでいる状態です。

.sshは700、id_rsaは600というパーミッションです。

プライベートキーがリモートサーバ（本番環境）にある状態だと思いますが
これはリスクがあるのではないでしょうか。

まず入り口での防御が重要です。
・アクセス制御
・firewall
・ログ監視・アクセス監視
・脆弱性チェック
ちょっと古いですが、IPAさんを参照するとかIPAさんを含め信頼できる情報をウォッチするのが良いです。

その上で思いつくままに、列挙

• 参考サイトにパスフレーズはうまくいかなかったからつけないと記載されていますが、きちんと適切な長さのパスフレーズを付与しましょう

キー作成でrsaで本当に良いのか確認しましょう
https://www.slideshare.net/hnw/edomaesec-20150124
http://mashi.exciton.jp/archives/250

• selinuxを有効に
• webと管理用（git含む）とを別のネットワークに（物理的に分けるのが望ましいが、ポートを分けるでも良いかも）

　そして、管理用はソースなどでフィルタ
githubもAPIを利用することでIPを特定可能
https://help.github.com/articles/about-github-s-ip-addresses/
https://developer.github.com/v3/pulls/
アクセストークンの権限を絞ることでさらにあんしん

Comments

[ruuusaamarki]

コメントありがとうございます。

たしかに専門家への相談がコスト的には安いのかもしれませんね。

＞まず入り口での防御
こちら今回はレンサバということもあり
あまり考えておりませんでした。
改めて指摘されるといろいろできそうな
感じもするので少し調べてみます。

ご提示いただいた資料のほうもありがとうございます。
理解するまでには時間がかかりそうですが
秘密鍵が結構シンプルな素因数分解で作られているのは面白かったです。
大変勉強になりました。ありがとうございました。

Answer 3

回答では無いです。ほぼ感想文ｗ
リンク先を見たのですが、ナゼか無駄にゆるい比較を使用しています。

if($payload['ref'] == $branch){

こんなところで、ゆるい比較使うスクリプトはたいていツギハギなんで、あまり本番環境で使用してほしくないなぁ。。。
webhook の仕様を確認してないけど、ちゃんと理解して、スクリプト見直したほうが良い気がします。
log ファイルがなんとなく不穏ｗ

Comments

[ruuusaamarki]

コメントありがとうございます。

ご指摘の通り何連鎖かしており、自分も少し改良して
記事書いてみようかな～なんて考えておりました^^；
改めて見直してみます。ありがとうございました。

Answer 4

まずは自動更新システムの構築、素晴らしいです。参考にしたいと思います。

さて、質問の、

.sshは700、id_rsaは600というパーミッションです。

プライベートキーがリモートサーバ（本番環境）にある状態だと思いますが
これはリスクがあるのではないでしょうか。

神経質に考えると、たしかによろしくないかもしれません。

とはいえ、サーバーへのssh接続情報を厳重に保管していれば、そこまで神経質になる必要はないと思います。サーバーにある鍵のパーミッションも適切です。

もう少しセキュリティを強固にしたいのであれば、

• XserverにSSHで繋げるマシンをIP制限などで限定する
• 踏み台サーバーを経由させなければ入れないようにする（上に似ている）
• ssh-keygenのオプションを細かく（桁数を多くする等）設定しておく

などが思いつきます。

以上、素人DevOps見習いの意見でした。

Comments

[ruuusaamarki]

コメントありがとうございます。

パーミッションの件はすこし安心できました。
ご教授いただきました
IP制限、踏み台サーバなども実際の運用を踏まえて考えてみます。
（AWSの際こういった手法を聞いたことがあったのですが
よく考えるとレンサバでもできますね）
keygenはたしか2048で作成していましたが
改めて調べてみると最近はどんどん桁数も増えているんですね。
このあたりも随時見直さなければなりませんね。
大変参考になりました！ありがとうございます！