「プライバシー」のシステム的な意味の変化が来ている
プライバシーは、セキュリティを考える要素の一つ「機密性」として語られてきたことなんですが、これまで「機密性違反を権限まわりの修正で対応する」とか「暗号化する」とか技術的にはそういう会話がありました。また、なんとなく「プライバシーポリシー」という言葉はサイトには書いてあるんですが、それほど実装チームが都度都度気にしているものではなかったように思います。
ここ数年、「プライバシー・バイ・デザイン」「セキュリティ・バイ・デザイン」という言葉がでてきたりして、ちょっと別のカットでの要請が大きくなってきました。GDPRやCCPAといった、プライバシーデータに関する強いコンプライアンスも、大きく叫ばれていますので、なんとなく気になってはいるのではないかと思います。
システムの面で最初に理解されていることは、「機能面の要求」や「実装面の要求」でしょう。ユーザのプライバシーを技術面で保証してくれ、と。認証認可や暗号化、またデータの適切な分散などで実現できるでしょう。
「運用管理面の要求」はどうでしょうか。これは誰に管理を許可するのか？どこの管理者がプライバシーデータを管理するのか？といったことです。域外移転、すなわち「どこの国からアクセスして管理されるのか」というところが話題になっています。
インターネット上の、どこのデータがどこの国のどのハードウェアに置いてあるかということを説明できることが、社会的要求になってきています。さらに、サービス連携によるデータの移転も、懸念されています。このような状況の中、プライバシーデータのオプトアウトはどうやって実装し、どうやって保証しますか？
みなさんの観察では、いかがでしょうか。
グローバル化が讃えられ、みんなにとって高速でメンテナンスが出来、安い費用で運用・開発が出来ればそれがベストだ！と思って日本から飛び出し、いろんなビジネスを、あちこち連携して作ってた人たちが、これらの要請にたいして「え、ホント？できてない・・・」となっています。
どこから考えれば良いのか
プライバシーデータの取り扱いは、後付けしにくい領域です。新たな要請に応じて柔軟に対応していかなければならないこともあります。
また、システム設計において、運用をどうするかという問題は、サーバとアプリケーションだけの問題ではありません。運用チームが用いるモニタリング、データのオペレーション、ユーザの管理など、その仕組みとアクセス元の制御まで考えなければならなくなりました。
これを不可逆なプロセスであるウォーターフォールで実現するのは大変です。あらかじめわかっている制約条件なら計画もできますが、システムは最初から大規模ではないかもしれませんし、追加された機能が特にプライバシーを強く求められる類のものだった場合には、当初検討していなかった運用管理上のコントロールを作り込まなければならなくなります。
つまり、システムを作る段階では見えてこなかったことを、段階的に追加実装することができる開発プロセスや開発手法をとる必要があります。ウォーターフォールかアジャイルか。これは、流行りのスタイルでも、エンジニアのやりやすさの問題でもなく、さらに大きな要請への対応が関係していそうですね。