セキュリティのこと

セキュリティを単独で語るのは無理

セキュリティのことを、他の部分と分離して一つの章にまとめるのは 実は、無理がある。

よくある間違いは、

という要求のもとで、作業をはじめて、「とりあえず、これこれとあの機能は 完成させた。残るのはセキュリティのことだけだからあとはよろしく」という パターンだ。
だめだめ。「これこれの機能」や「あの機能」の 設計段階から、セキュリティのことを考慮にいれた設計をしていなければ、 全部完全に作り直さなければどうにもならないはめになるのが関の山だ。

セキュリティというのは、後から追加することはすごくむつかしい。
というのは、セキュリティのレベルをある一定の水準に保つためには、 「してはいけないこと」「採用してはいけない技術」というのが、山ほどあるのだ。 そしてそれらの「してはいけないこと」というのは、実は、 「ある種のことを簡単に実現するための方法」であったりする。
とりあえず「これこれの機能」は完成させましたといったときに、 中身を点検すると、これらの「してはいけない」が満載だったりする。 こういう場合には、もう最初から作り直す以外に方法はない。

セキュリティ機能を「後から追加できるのは、最初の設計がセキュリティに 配慮している場合だけ」だ。

手法を制限された条件下で作り始めなければ、決して安全なものはできない。 安全は、後から足し算でできるものではなく、引き算された環境で得られるものだ。

だから、この文書では、あちこちにセキュリティがらみのことが書かれている

だから、人によっては、「あれを使えば、同じことがもっと簡単にできるのに」 と思うことが、別の方法で実現されていると思うことも多いと思う。

たとえば、「マイクロソフト社の製品を採用する」というのも、 セキュリティの観点からは、「してはいけないこと」の一つ。 まあ、現実には、完全に排除するのは困難なので、適当なところで 妥協するしかないのだが。

「アクセスを使えば、もっと簡単に素人でもデータベースを操作できるのに」 と思う人は多いと思う。
そしてそれは、「アクセスなら自分でも操作できるのに、なぜわざわざ、、、」 という気持ちの裏返しなのだと思うけれど、自分は、「アクセスを使ったら セキュリティは保てない」と思うのでアクセスは使わない。
たとえば、アクセスのプログラムで、ユーザーの入力を文字列変数に代入すれば、 代入された文字がデータベースの中にキャッシュとして残ってしまう。 データベースファイルをコピーできる権限があれば、その中の文字列を 検索すれば使った人のパスワードを覗き見ることができる。

もちろん、何がしてよいことで、何がしていけないことかという基準は、 要求されているセキュリティのレベルに依存する。
「この部分はどうなってもいい」と部分を敢えて用意するというのも 戦略としてはありうるので、そういうところでは、それこそ「何でもあり」 というのも正しいやり方だ。

ソーシァルエンジニアリングを軽視してはいけない

住基ネットの二の舞はごめんだ

教会同士をネットワークでつないだ場合にまず必要なことは、 信徒名簿のようなプライバシー情報が流出しないだろうかという 不安を解消することだ。
もちろん、データを小教区だけにもって外界とのやり取りは いっさいしないということであれば、ファイヤウォールを きちんと設定してユーザー教育をきちんとすれば、 少なくとも外部からの攻撃に対してはそれなりの 安全性を保つことはできるだろう。 (ただし内部からの流出を防ぐのはこれだけでは不十分だ。 住基ネットの間違いにはいろいろあるが、 その一つは内部からの流出を軽視しすぎている点だとおもう。)

とはいっても、いまどき、おおもとのデータとなる信徒台帳そのものは 鍵のかかる場所にしまわれているとはいえ、日常用途に使われる信徒名簿は、 ワードなりエクセルなりで電子化された状態でPCに保存されているのが 普通だ。
教会内部をLANでつないだときに、これらのファイルがあやまって見えてしまうことを 防ぐのは容易なことではない。
(通常の操作の元で見えなくするというのはそれほど難しいことではない。 ただ、人は適当なところにコピーを作成するものだ。本人が気づかなくても プログラムが勝手にバックアップを作成することもあるし、ごみ箱にデータが残っていることもある。 元のファイルのパーミッションが他人には読めないように設定してあっても、 バックアップしたファイルが誰でも読み込み可になっていたりする。)

よくある例

データベースのセキュリティ

仕事がら、他のソフトウェア会社の作成した、「セキュリティに配慮した」 といわれるデータベースシステムを覗く機会も多いのだけれど、実際に 中身を調べてみると、「これのどこがセキュアなの?」と思うことが多い。

一番典型的なのは、ユーザーの画面からの操作ではそこそこ権限設定も されていて、できて欲しくないことはできないようになっているけれど、 同じパスワードで、データベースに直接接続してみると(こういう汎用の ツールは大抵のデータベースには付属している)なんでもできてしまう、 というものだ。

よくあるのが、「認証」「更新」という二つのステップで構成されている 処理が、独立した2つのプログラムとなっているもの。 普通のプログラムを利用している限り、常に、2つのプログラムがこの 順番で呼び出されることになっているので問題は発生しないのだが、 別のプログラムを用意すれば(自分で作成すれば)「更新」のプログラムだけを 単独で呼び出せる(言い換えると「認証」部分をスキップできる)というものだ。 ( というか、こうなっているのが現実にはほとんどだ。)

もっと極端なのは、ユーザーインターフェース上はパスワードに入力が 必要だけれど、データベースそのものへのアクセスにはパスワードが 不要なもの。あるいは、データベースへのアクセスは特定のユーザーの 権限でアクセスするのだが、いったんアクセスしてしまうと、他の人の パスワードが平文でデータベースの中に誰でも見える形で記録されている というもの。

ひどいのは、管理者権限のパスワードがデフォールトのままだったり、 user名が adminで、パスワードが adminだったりする。 こんなパスワードを使っているソフトウェア会社が、「セキュリティに 配慮しました」といっても誰が信用するのだろう。