0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

個人情報の保護ってなにをすればいいの?

Last updated at Posted at 2021-05-16

はじめに

個人情報保護という単語はよく聞くけど、具体的に何が個人情報として扱いとなるのかが分からない。メールアドレスって個人情報なの? よく、「個人情報保護大丈夫?」といわれるけど、具体的に 何をすればいいの? この疑問について、Webサイトの開発者側の視点で調べてみました。

個人情報として保護の対象となるもの

「個人情報」として扱うものの定義です。一言でいうと「特定の個人を識別できるもの」なのですが、例えば「メールアドレス」はどうでしょうか。「abcd01234@...」のように意味を持たない文字列のメールアドレスは個人情報とは言えませんが、「氏名@会社名」のように「どこどこの会社の〇〇さん」といったことが推測できるものは「個人情報」として扱われます。同様に、留守番電話の音声でも、「特徴のある声で、聞くだけで特定の個人を推測できる」ものは個人情報として扱われます。一般的に特定のサイトのIDなどは個人情報ではありませんが、Twitterのように投稿内容によって個人が特定できるものであれば、そのIDは個人情報として扱われます。

「同じ情報でも個人情報として扱われるものと、そうでないものがある」ところが難しいところで、収集側とては1つでも個人情報が含まれる可能性があるものは個人情報として扱う必要があるということのようです。

逆に個人情報の保護対象外になるもの

基本的に保護の対象となるのは、業務目的の達成や管理のために取得した個人情報や委託された個人情報が対象となるため、以下のようなものは対象外になるようです。

・倉庫業務などで預かった品物に含まれている個人情報。ただし、業務でそれを識別する場合は保護の対象。
・社員が個人で作った年賀状を出すための住所録など

業務作業場、認知しないものは個人情報の保護対象外になります。
(が、個人情報を含む可能性があるものは、個人情報に準拠した扱いが求められます)

フリー入力欄で個人情報を入力された場合、「業務でそれを識別するわけではないので対象外」とは言えますが、取り扱い的には個人情報に準拠する必要があるといったところでしょうか。そうなると、基本 全てがその対象になるともいえますね。

個人情報の取り扱いについて

基本は下記3つと考えています

その利用用途を明確し、決めた利用用途以外に使うことを禁止します。

原則ですね。業務上 必要であったり利便性がよくとも、利用者からすると、知らない間に個人情報が第三者に渡っていると困りますよね。なので、利用用途を明確に利用者とその内容について合意を取ることにまります。

合意のとり方は、サイトだと利用者対して説明文を表示した上でチェックボック等で行ったりします。
ポイントとしては、「個人情報を収集するタイミング(フォーム送信)」と合意を取る部分が画面遷移的に近いこと (1クリック程度)であることがあげられます。

利用者からの 閲覧/変更/削除 の依頼に対して速やかに対応できる体制を整えます。

利用者が、容易に自身の個人情報の 閲覧/変更/削除 を要求できるようにする必要があります。
これは、サイト上に機能を実装する という方法以外にも、問い合わせ窓口を用意しメールや電話などで要望を受け付ける形でも問題ありません。ただ、要望をうけつけてから対応まで速やかに行う必要があります。

あと付け加えるとすると、犯罪性があったり開示することで生命の危険やセキュリティ上の問題が生じる場合は、要求を拒否することもできるようです。

業務遂行の上で不必要となったら、速やかに個人情報を削除します。

予め決められた用途での利用が終わり次第、速やかに削除することになります。ここで重要となるのが、「何を持って利用終了とするか」でしょうか。

セキュリティ面

これは業務によって異なるため、「適切に管理、運用する」という一言となるのですが、よく行われている施策について上げてみます。

個人情報を扱う端末を限定する。

個人情報に触れる端末を限定します。これは、管理画面のような個人情報が表示される画面に対してのアクセスだけでなく、直接データベースにアクセスする端末なども含みます。これらの端末は、覗き込みの防止や、利用者の把握ができるよう、一般社員のいるオフィスから切り離し、個室などで管理します。また、そのPCからはUSBや他クラウドストレージなどを経由しデータを受け渡せないように、セキュリティをかけることもあります。

個人情報をマスクし、アクセスできる端末を増やす

と入っても、運用上 特定の端末からでしかアクセスできないと不便です。
ですので、一般端末からアクセスできる範囲は、個人情報のマスク化なので目に触れないようにする対応を取ることもあります。ただ、BUGなどの要因により流出するリスクがあるため、必要外にはこの対応はとりません。

アカウト管理 / アクセスログを取る

一人ひとりに対してアカウントを発行し、誰が いつ なにをしたのか がわかるようなアクセスログを取ります。
またアクセスログは、例えば同じAWSアカウント上に出力していると、開発者などがログの改ざんができてしまうため、ログ管理用のアカウントに転送するなどでして、関係者が改ざんできなような対応とることもあります。

個人情報を扱う運用フローを決めておく

サポートなど個人情報に触れる運用や、「不要となったタイミングで削除する」を実現するための「不要なタイミング」の判断基準と「誰がいつ削除するのか」を予め決めておき、それに逸脱しない形で運用を進めます。

技術的なセキュリティの定石を踏む

クロスサイトスクリプトや、AWSでいうと Well-known architect に沿っているか などといった、技術的なセキュリティ対策の定石を踏んでいるか という話になります。

こちらは、セキュリティについてまとまった書籍や他の方の記事が参考になるかと思います ^^;
※個人的には、「体系的に学ぶ 安全なWebアプリケーションの作り方」がオススメです。

0
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?