Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

[WIP]画像検索機能の実装 #57

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

usk108
Copy link

@usk108 usk108 commented Jun 28, 2015

flickr APIを追加

@usk108
Copy link
Author

usk108 commented Jun 29, 2015

シークレットキーの扱い失念していました…
その他にもたくさんご指摘ありがとうございます
質問が2つあります
①こういう風に公開すべきでない情報は変更しても記録として残ってしまってるんですが、全データから特定のコード(今でいうところのキー)を消す手段はあるんでしょうか?
②こういう鍵の情報をグループの中で共有したいときは暗号化とかしないといけないんでしょうか?いつもはこうしてる、みたいなノウハウがあったら教えていただけると嬉しいです

@Gaia-Murata
Copy link

@usk108 遅れてごめんね
1に関しては、コミットごと消すしかないかなー、キーを定数クラスにでも逃して、それをignoreして、コミットしなおすのが正しいかな。

2に関してはグループ内でツールを使うのがいいかもね、どんなキーを利用するかにもよると思うけど、http://www.moongift.jp/2013/12/teampass-チームで使えるパスワード管理/
みたいなツールでパスワードとかキーは管理しているね。
どうしても漏らしたくないものに関してはipMessengerとかで温もりのある手渡しでやってるかな

@co3k さんが詳しいと思うから、見てればなにかいい助言をくれるかも...

@co3k
Copy link

co3k commented Jul 8, 2015

②こういう鍵の情報をグループの中で共有したいときは暗号化とかしないといけないんでしょうか?いつもはこうしてる、みたいなノウハウがあったら教えていただけると嬉しいです

鍵管理は非常に頭の痛い問題で、こうしておけば正解、というものはなかなかないです (XSS 脆弱性などのように脆弱点や対策に関する定石が決まっているものとは対照的に)。それから一口に「暗号化」といっても、暗号化には鍵が必要で、それではその鍵はどうやって共有すればいいのか……と、結局のところ同じ問題に行き着いてしまいます。

ではどうすればよいかというと、 GitHub 上に鍵情報を置くことによって想定される脅威、リスク、それから鍵によって期待するセキュリティ上の効果から逆算して、妥当な対応を決めるという、一般的なセキュリティ対策のステップを地道に踏んでいくしかありません。

ということで地道に考えてみましょう。

まず、「グループの中で共有したい」ということは、裏を返せば「グループ内のメンバーのみ閲覧を許す」というのが主たる要件であると言えるかと思います。ありていに言えばこの種の権限設定が使える手段によって鍵情報を保護すればよいということになります。

たとえば、 GitHub にプライベートリポジトリを作ってメンバーをコラボレーターに追加したり、 Google Drive で特定の Google アカウントに対して閲覧を許可したり、秘密の Facebook グループを作ってそこに共有したり、というのが手っ取り早いでしょう。
ただし、これらのサービスを用いる場合、メンバーのうちの誰かのアカウント情報が脆弱 (フィッシングに遭ってしまった、弱いパスワードを用いている、など) となったとき、ほかのメンバーのアカウントが攻略されなかったとしても鍵情報を窃用されてしまうというリスクは享受しなければなりません。そのようなリスクに対しては、普段と違う環境からログインされた場合に警告してもらう (=そういう監視をおこなっているサービスを利用する)、二段階認証を利用する、特定の IP アドレス以外からの閲覧を許可しない、などの設定が (もしできれば) 有効でしょう。

ガイアさんがおっしゃるように共有のパスワード管理ツールやサービスを用いるのも妥当です。これらのツールにおいてはセキュリティに特化した保護機構 (先述の IP アドレス制限など) が期待できるだけでなく、サービスがクラックされて DB が直接参照されてしまった場合でも、攻撃者が容易に元の情報を得られないような形で情報が保存されていることがほとんどです。この種のサービスを使っている場合は、鍵情報をコード上から参照できる設定ファイルに自動的に反映するといったことも頑張ればできます。

もしくは、イントラネット内に平文もしくは暗号化 (この暗号鍵は別な手段で配布し、使い回す) された鍵情報を置くという手もあります (このあたりは権限管理が将来的にも妥当な状態が維持され続けるかどうか保証する仕組みを設けるなど、それなりに安全に運用するのに工夫は必要です)。人数が限られているのであれば物理的な手渡しも有効ですね (手渡しした鍵情報を適切に破棄できているかどうかは確認しないといけませんが)。

あるいは、 GitHub を用いている前提であれば、チームメンバー個々人が GitHub に登録している SSH 公開鍵 (これは誰でも閲覧することができます) を用いて暗号化して鍵を受け渡し、それぞれの秘密鍵で復号してもらう、といった運用も可能だろうとは思います。この運用ができるメンバーであれば、鍵を暗号化するための鍵、みたいなややこしいことを考えなくてよいので楽ちんです。

まとめると、

  • A) グループ内のメンバーだけの閲覧に制限できれば充分な場合 : そういう権限設定ができるサービスを使う or イントラネットで共有する
  • B) メンバーへのなりすましによるリスクを想定する場合 : その種の警告をしていくれるサービスを使う and / or 特定の環境からのアクセスに制限する
  • C) サービスがクラックされた際のリスクを想定する場合 : 情報を格納する際に暗号化してくれるサービスを使う or 自前で暗号化する

というところでしょうか? SSH 公開鍵による暗号化は一発で A, B, C すべてを満たすことができてすごいですね。でも配布が面倒かな。

以上、だらだら書いちゃいましたが参考になれば幸いです。

ちなみに僕が直近で採用した方法としては、以下の前提を置き、

  • 会社内のメンバーには (同じ部署でなくても) 公開して構わない
  • 最悪の場合でも、漏れたら変えられるし、被害もそれほど甚大ではない (メンバーのなりすましのリスクは許容する)
  • しかしなりすましは困難になるように、特定ネットワークからの利用にのみ制限したい

その結果、イントラネット内のファイルサーバに設定ファイルを設置し、デプロイ時にその設定ファイルを自動的にコピーするような運用をおこなうようにしました (つまり、メンバーは特定のネットワークにいる限りにおいて、鍵情報について意識しなくてもよい)。一見危うく感じるかもしれませんが、適切にリスクを見積もれてさえいればこういう運用もアリです。

@usk108
Copy link
Author

usk108 commented Jul 30, 2015

ガイアさん,えびさん,ありがとうございます!
お返事に気づかず反応が遅くなってしまい申し訳ありません.
とても参考になりました.
その時々にあわせて妥当な処置を考えればいいということですね.
今の自分の知識ではまだまだ難しそうですがこれからこういうことも増えそうなので教えていただいたことも参考にして勉強させていただきます.
ありがとうございました!

@hironomiu
Copy link
Contributor

👍

頑張って!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants