セキュリティとは
何かを安全に保護することです。 ここでは、基本的にはコンピュータ関連のことを書きます。
インフラ
原則
- セキュリティアップデートはなるべく早く適用する。
- 容易に止められないシステムの場合は、脆弱性の内容を検証し、後回しにしていいか判断する。
- リモートから攻撃されるものは早めに適用する。
- ローカルのみしか攻撃されないものは、システムによっては適用を遅らせても構わない。
- SELinuxはオンにする。
- 不要なサービス、ポートは開けない。
- サーバの情報は露呈させないほうがいいが、あくまでも攻撃されにくくするためであり、本質的な解決案ではない。
開発時
正しい方法を知る
例えばクライアントが渡す全てのパラメータは変更(改ざん)できると認識すること。
- フォームで渡すパラメータ
- アップロードするファイル
- User-Agent
- HTTPヘッダ
要件が大事
セキュリティを考える時に重要なのは、要件です。
- どの情報を秘匿すべきか
- パスワードはもちろん第三者に漏れてはいけません。
- メールアドレスはパスワードに比べると秘匿度は低いです。
- セキュリティだけでなく、プライバシーの観点からも必要です。
- 誰から守るものか
- インターネットの悪意を持った人(クラッカー)
- 社内の悪意の利用者は仮定すべきか
- サーバのローカルアカウントからの攻撃は仮定すべきか
- 物理的にアクセスできる人からの攻撃を仮定すべきか
- どのプロトコルを使うか
- httpsによるアクセスは、第三者からの盗聴はほぼ気にしなくてよい。
- ブラウザの拡張機能や、XSS攻撃による問題はあります。
- メールは外部から盗聴される可能性がある。
- Webメールはhttpsなことが多いですが、元々転送を前提としていて、暗号化は後付けのため。
- httpや「不正な証明書(いわゆるオレオレ証明書)」は全く安全ではない。
- httpは盗聴が容易。
- 不正な証明書は中間者攻撃をされる可能性がある。
- 不正な証明書でも安全な方法で取得してクライアントに入れれば安全とは言えるが、基本的には面倒なだけ。
- httpsによるアクセスは、第三者からの盗聴はほぼ気にしなくてよい。
- どれくらいの強度が必要か
- すぐに無効化できるなら問題ない(ワンタイムパスワード)
- 絶対に破られてはいけない
といった情報が重要です。
アルゴリズムを隠すことで安全性を担保してはいけない
これは「ケルクホフスの原理」として知られています。 オープンソース・ソフトウェアや標準化された暗号は アルゴリズムが公開されることを前提に、安全性を確保しています。
これはソースコードを公開しろと言っているのではなく、 「ソースコードを公開してもその仕組みは安全ですか?」という問いかけですね。