基本的なWebセキュリティ 第02回 20年01月 / 最終更新：2020.01.20
Webの受発注を拝見していると、特にここ昨今で「セキュリティなんて気にしない」という剛毅な発言はまずもってお目にかかれないのですが。
ただ一方で、特に私は受注する事が多いので、発注側から「セキュリティをしっかりしてください」と問われた時には「御社にはなにか指針がありますか？」と伺うのですが、必ずしも全ての会社さまで「しっかりした指針がある」訳でもないように見受けられます。
そういった時に「比較的使いやすいセキュリティの指針」があったり、チェックにもいくつかポイントがあったりするので、今回はそういった事を少しお話できれば、と思います。
まず、そもそも「セキュリティ」ですが。大雑把に切り分けても
・インフラに起因するセキュリティ(物理/ネット)
・サーバに起因するセキュリティ
・Webサービスに起因するセキュリティ
があり、多岐にわたっています。
まず「インフラに起因するセキュリティ(物理)」ですが。
昨今では「データセンタ」や「クラウドサーバ」を使う事が多いので、「インフラに起因するセキュリティ(物理)」はある程度安心出来ると思います(そういう業者を選びましょう)。
ネットワーク、サーバについては、ここもお話をしていくと長くなるのですが
・適切なネットワーク設計をする
・不要なサーバにはglobal IPを割り振らない(公開しない)
・不要なportは閉じる
・不要なサービスは入れない動かさない
・OSやミドルウェアのアップデートはある程度こまめにやる。「洒落にならないセキュリティホールのニュースが出た」時は、速やかに対応する(事ができる体制を整えておく)
あたりが、基本ですが重要になります。
上述を踏まえた上で、本稿でお話をするのは、最後の「Webサービスに起因するセキュリティ」です。
微に入り細を穿つところまで考えていくと色々とあるのですが。
まず「最低限」押さえておきたいのが、独立行政法人情報処理推進機構(IPA)さんの「安全なウェブサイトの作り方 https://www.ipa.go.jp/security/vuln/websecurity.html」にある、安全なウェブサイトの作り方」というPDFです(現在、改訂第7版になっているかと思います)。
こちらと、合わせてついている「セキュリティ実装 チェックリスト(Excel形式)」を使うのが、まずはよいように思います。
これで「万全」という訳ではありませんが、「これすら出来ていないようではお話にならない」ので、まずはベースラインの確保、を確実にしておきましょう。
また、2020年には「ウェブ・セキュリティ試験」という試験が出てきますので。
内製であれば内部のエンジニアさんに、外注であれば発注先のエンジニアさんに、とりあえず「この試験を知っているか？」を尋ねてみて、セキュリティに対する意識を確認するのもよいと思います。
さて。
概念的なお話ばかりでも幾分つまらないかと思うので、いくつか特に「重要度の高い」ポイントを、少し書いていきたいと思います。
今回は「パスワードの保存の仕方」について言及をしてみましょう。
そんなに頻繁にあるお話でもないのですが。
情報漏洩のタイミングで「パスワードが一緒に漏洩する」という事が、情報漏洩をしたタイミングでは、そこそこの頻度で発生しています。
この漏洩したパスワードが「十分な考慮のされている、パスワードhash値」であれば多少はマシなのですが、これが「十分に考慮されていない、単純なパスワードhash値」の場合、状況によっては「比較的簡単にクラック」が出来る事があります。「レインボーテーブル」というワードでググると少し詳細が出てきますので、興味があったら調べてみてください。
そうして「パスワードをそのまま(平文で)」保存しているケースが、やはり「比較的、稀(だと思いたいです)」にありまして、この場合「もう一段階、シリアス度合いの高い」ニュースになります。
ニュース検索で「パスワード 平文 漏洩」のキーワードで確認すると、2019/12にもそういったニュースが出ているので、やはり「稀にはあるものだなぁ」と思われます。
パスワードは必ず「ユーザ毎に異なるsalt(文字列)を使って」「計算量の多い(計算の遅い)ハッシュ関数を使う、またはストレッチングと呼ばれる"ハッシュ関数の繰り返し"を行う」必要があります。
もしPHPを使っているようであれば、password_hash() という関数が便利でしょう。「PHP5.5以降」ですが、PHP5.3.7以降であれば「ユーザーランドでの実装( https://github.com/ircmaxell/password_compat )」があるので、こちらを使って実装が可能です。
今から発注するものについては勿論「最低でも上述を指定する」必要がありますが、現在運用中のサービスについても、上述が徹底されているか？ を確認しておいたほうが、色々と安心かと思います。
また、もし「平文で実装しているサービスがある」場合、出来るだけ早急に「十分な考慮のされている、パスワードhash値」に置き換える事を強くお勧めいたします。
こういった「ピンポイントで重要度の高い(何かがあった時に問題の度合いが高くなる)」ところをしっかりと押さえておくと、発注側としてもとてもよいのではないか、と思いますので、是非覚えておいてください。
次回も、「重要度の高い」ポイントをもう何点かお話したいと思います。
サービス・ソリューション
