Privacy Violation: Unobfuscated Logging

顧客パスワードや社会保障番号などの個人情報の取り扱いを誤ると、ユーザーのプライバシーが危険にさらされるだけでなく、多くの場合に法律違反となります。

次の場合に Privacy Violation が発生します。

1.ユーザーの個人情報がプログラムに持ち込まれる場合。
2.コンソール、File System、ネットワークなどの外部の場所にデータが書き込まれる場合。

例 1: 次の脆弱なコードには、シークレット "admin_password" を難読化せずにログに記録できるようにする構成ステートメントが含まれています。

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

Example 1 のコードは、secret が False に設定されているため、admin_password を平文 (難読化なし) に書き込んでログに出力します。多くの開発者がイベントログをデータの安全な格納先として信頼しがちですが、特にプライバシーに関わる場合は盲目的に信頼しないでください。

個人データがプログラムに持ち込まれる方法はさまざまです。

- パスワードもしくは個人情報としてユーザーが直接入力する。

- アプリケーションにより、データベースなどのデータ ストアからアクセスされる。

- パートナなどの第三者から間接的に持ち込まれる。

個人情報とのラベル付けがされていないデータも、別のコンテキストでは個人情報としての意味を持つことがあります。たとえば、学籍番号は、学生の個人情報に結びつくような明示的で公開されたマッピングがないので、通常、個人情報とは見なされません。しかし、学校が学生の社会保障番号に基づいて学籍番号を生成する場合は、学籍番号は個人情報と見なすべきです。

多くの場合、セキュリティとプライバシーの問題は互いに競い合っているかのようです。セキュリティの見地からは、異常な活動があった場合に後で識別できるように、重要な操作はすべて記録するべきです。ただし、個人データが関係する場合、それによりリスクが生じる可能性があります。

個人データの安全でない取り扱いにもさまざまな形態がありますが、一般的なリスクの原因は不適切な信頼にあります。多くの場合、プログラマはプログラムが実行される操作環境を信頼するので、File System やレジストリなどローカルで制御されているリソースに個人情報を格納することも適切だと考えます。ただし、一部のリソースへのアクセスが制限されている場合も、実際にアクセス権を持っている個人なら信頼できるとは限りません。たとえば、2004 年には、AOL のある不心得な従業員が、約 9,200 万人の個人顧客の電子メール アドレスを、海外のギャンブル Web サイトのマーケティングをしているスパマーに販売しました [1]。

こうした悪用が注目を集めたため、個人データの収集と管理に関する規制は厳しさを増しています。会社などの所在地や業種、処理する個人データの性質によって異なりますが、以下に挙げる連邦や州の規制の遵守を求められる場合があります。

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

これらの規制にも関わらず、Privacy Violation はますます高い頻度で発生し続けています。