アカウント名:
パスワード:
セキュリティが高ければそりゃいいんだけど、人件費を無視しやがるお偉いさんがいる時もある。運用でカバーするAというルールを作る->Aを完全にカバーできる機械的な仕掛けBを作る->お偉いさん:「念のため、AもBもやってね!」Bではカバーできない事例が見つかる->運用でカバーするCというルールができる->機械仕掛Bが改良されDができる->お偉いさん:「念のため、A,C,Dをやってね!」以下、運用でカバーするルールは増え続けるorzどんなに意味が無いor効果が小さくても、逆に安全に危害を与えるルールじゃないかぎり消えないのよね・・・。「安全は全てに優先する」の号令のもと、運用でカバーするために全従業員が費やす時間は無視されるorz
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
セキュリティ、セキュリティもいいけれど (スコア:2)
意識するあまり、運用コストが高くついてしまう場合がある。
守るべき情報が正しく守られるなら、それ以外の部分は必要以上に厳しくするとコストの上昇を招くだけで、費用対効果(※)が合わなくなる時がある。
※ここで言う費用対効果は、漏洩した時の被害で発生する信頼の回復の費用も含む。
クライアントセキュリティとサーバ(業務データ)のセキュリティは分けて考えたいなぁ・・・。
それにちゃんとファイアウォールを考えるなら、サーバとクライアントの間に専用のセキュリティアプライアンスなりWAFなりを設置するのがいい(楽)と思う。
#ファイアウォールがあれば安心って考え方がちゃんちゃらおかしい。
#L3のファイアウォール程度なら、正直アプリの正常通信に見せかける攻撃にはほとんど意味が無い。
#ベネッセだって結局ソーシャル?権限を持った人間の問題だったし。
愚痴 (スコア:0)
セキュリティが高ければそりゃいいんだけど、人件費を無視しやがるお偉いさんがいる時もある。
運用でカバーするAというルールを作る->Aを完全にカバーできる機械的な仕掛けBを作る->お偉いさん:「念のため、AもBもやってね!」
Bではカバーできない事例が見つかる->運用でカバーするCというルールができる->機械仕掛Bが改良されDができる->お偉いさん:「念のため、A,C,Dをやってね!」
以下、運用でカバーするルールは増え続けるorz
どんなに意味が無いor効果が小さくても、逆に安全に危害を与えるルールじゃないかぎり消えないのよね・・・。
「安全は全てに優先する」の号令のもと、運用でカバーするために全従業員が費やす時間は無視されるorz