データベースは主に、さまざまなビジネス上の重要なアプリケーションを支えるために使用されます。多くの種類のデータを保存できます。とはいえ、データベースに決して保管してはいけないものがいくつかあります。
これらの基本的な データベースセキュリティ 手法は、データを保護するのに役立ちます:
保護されていない認証情報
おそらく当然のことですが、データベースに平文のパスワードを保存するのは得策ではありません。
もしハッカーがこの表のデータにアクセスできた場合、その人(またはハッカー)はすべてのユーザーのすべてのパスワードのリストを手に入れます。これらのパスワードは平文で読めるテキストなので、ハッカーがそのユーザーであるかのようにシステムへログインするためにそのまま使えます。 大したことに思えないかもしれません。ハッカーがすでにシステムにアクセスしているのなら、なぜログインが必要なのでしょうか?問題は、人々がしばしば複数のアカウントに同じパスワードを使い回していることです。ハッカーがユーザー名とパスワードを持っていれば、その情報を他のサイトでも利用できます。 では、この問題をどう回避すればよいのでしょうか。保存する前にパスワードを暗号化してください。この処理はしばしば「ハッシュ(hashing)」と呼ばれ、さらに「ソルト(salting)」と組み合わせることもできます。
ハッシュ(Hashing) は、入力されたパスワードにアルゴリズムを適用して、それを暗号化することです。暗号化した結果を、そのままデータベースに保存できます。このパスワードを照合するには、システムがユーザーの入力値に対して同じハッシュ処理を行い、出力結果を以前に保存しておいたハッシュ値(正しいパスワード)と照合します。 多くのプログラミング言語には、この処理を代行してくれる組み込み機能があります。 要するに、データベースに平文のパスワードを保存しないでください。
重複データ
データベースに重複データを保存するのは、よい方法ではありません。データベース内のより多くの領域を占有します。データベースが大規模であれば、その量はかなり大きくなる可能性があります。また、いくつかの場所で同じデータを更新する必要があるため、データを更新するときに問題が起きることがあります。 唯一の例外は、データウェアハウスを作成している場合です。この種のデータベースは、更新よりも高速な検索のために最適化されており、通常は重複データを含みます。
データを保存するためにリレーショナルデータベースを使う利点の1つは、データを複数のテーブルに保存でき、各テーブルが1つのエンティティを表し、それらが互いにリンクされることです。これは「正規化(normalization)」と呼ばれます。これにより、エンティティごとに1つのテーブルを用意し、ID番号(またはその他のキー値)を使ってテーブル間を関連付けることができます。
つまり、いくつかの値に変更が必要になった場合でも、データを更新しやすいということです。さらに、保存スペースも節約でき、データを変更するときのパフォーマンスが向上することもよくあります。
画像などのファイル
データベースでは、画像などのファイルをデータベース内のテーブルに格納できます。
さて、(Oracle の BLOB データ型のように)ファイルを保存するためにテーブルやカラムを作成することはできますが、それは「そうすべき」という意味ではありません。データベースのテーブルにファイルを保存するということは、ファイルにアクセスするためにデータベースのロジック(必要に応じてアプリケーションのロジックも)を使う必要があるということです。これによりデータベースのサイズが大きくなり、パフォーマンスも低下します。さらに、バックアップやデータの破損への対応が難しくなります。ファイルや画像を保存するより良い方法は、ファイルサーバーを利用することです。ファイルサーバーはまさにそのために作られています。そうすることで、より高速なファイルアクセス、ファイルのメタデータに容易にアクセスできること、そしてバックアップ/リストア機能をより簡単に行えることが可能になります。
クレジットカード情報
最後に、どうしても必要でない限り、クレジットカード情報をデータベースに保存すべきではありません。
これには、クレジットカードの名義人名、番号、CVV 番号、有効期限が含まれます。関わるリスクがあまりにも大きいのです。もしハッカーがあなたのシステムからクレジットカード情報にアクセスできてしまったら、あなたの会社と顧客に大きな影響が及びます。さらに、クレジットカード番号を保存する場合は、厳格な基準(つまり PCI DSS)を満たしていることを確認するために、外部監査を受ける必要もあります。これは IT 部門の負担を増やし、追加の費用にもつながります。より良い方法は、Authorize.net や PayPal のような既存のソリューションを利用することです。これらの組織はすでにソフトウェアを開発しており、コンプライアンスも証明していて、多くの他社もすでに利用し信頼しています。そもそもクレジットカード情報を保存しない方がよいのです。保存することはリスクに見合わず、他社のほうがより適切に対応しています。
共有する
もっと詳しく
著者について
Ben Brumm
ソフトウェア開発者 & ビジネスアナリスト
Ben は、11 年以上の経験を持つソフトウェア開発者兼ビジネスアナリストです。オーストラリアのメルボルンを拠点に、フルタイムの仕事ではデータベースと SQL に携わってきました。また、Oracle データベースのトピックを教える DatabaseStar.com サイトの創設者でもあります。ソフトウェアとデータベースへの情熱は、1990 年代後半に高校でコンピュータ クラスを始めたことがきっかけで、それ以来ずっと大きくなってきました。