新規ステムの開発で、特定のデータのみを暗号化／複合化する仕組みが必要になった。

下記の順にデータが流れる場合、暗号化／複合化はどこでやるべきか？

FE（フロントエンド） → BFF（Backend For Frontend） → BE（バックエンド） → DB

結論からいうと、今回はBFFで実施します。

・BE・DBで暗号化しても、API実行権限があれば、データの中身が見えてしまう

・ログ等に機密データが出力されてしまうことを未然に防ぐ

・機密データは、保存のみで検索や集計等で使用しない

・運用しやすいように、機密データ以外は、データは容易に閲覧できるようにしたい。

1. FE（フロントエンド）で暗号化

• やること: ユーザー入力段階で暗号化。

• メリット: ネットワーク経路上で平文が漏れない。

• 注意点:

  • 鍵管理が課題（対称鍵なら安全に共有、公開鍵暗号なら公開鍵で暗号化）。

  • BFFやBEでは暗号化データしか扱えず、検索や加工が難しい。

• 例: パスワードやクレジットカード番号の暗号化。

2. BFFで暗号化／複合化

• やること: FEからの平文を受けて暗号化、または暗号化データをFEへ返す場合は複合化。

• メリット: FEを変更せずにセキュリティ強化が可能。

• デメリット: ネットワーク上はFE-BFF間で平文が流れる場合がある。

3. BEで暗号化／複合化

• やること: DBに保存する前に暗号化、取り出すときに複合化。

• メリット: DBに平文が残らない。

• 注意点:

  • BEに平文が存在する時間があるので、BE自体のセキュリティが重要。

  • データの検索や加工が必要な場合は工夫が必要（暗号化検索など）

4. DBで暗号化（TDEなど）

• やること: BEから平文でDBに入れても、自動で暗号化。

• メリット: アプリ側はほぼ意識せずに保護できる。

• デメリット: DBにアクセスできれば平文は見える。アプリ側で暗号化している場合ほど安全性は高くない。

The following two tabs change content below.

• この記事を書いた人
• 最新の記事

有村克志

フリーランスのシステムエンジニアしてます。

最新記事 by 有村克志 (全て見る)

• データ暗号化／複合化はどこでやる？ - 2025年11月1日
• auth0で異なるドメインのSSOを解決したい - 2025年10月1日
• auth０を使用したローカル開発環境の作成 - 2025年9月1日