Notes

Web API認証方式のパターン
https://architecting.hateblo.jp/entry/2020/03/27/033758#1-%E6%A8%99%E6%BA%96%E5%8C%96%E3%81%95%E3%82%8C%E3%81%9FHTTP%E8%AA%8D%E8%A8%BC%E6%96%B9%E5%BC%8F

Basic認証、Digest認証、Bearer認証、OAuth認証方式について
https://architecting.hateblo.jp/entry/2020/03/27/130535

Web APIで発生するエラーの対処
https://architecting.hateblo.jp/entry/2020/08/10/011339

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた
https://qiita.com/uasi/items/cfb60588daa18c2ec6f5


GDPR対応のポイント
https://japan.zdnet.com/paper/30001027/30002557/#dl_start

→DB接続ユーザの使い回しもNG…？？




※現行システム側での認証・認可をどう捉えるべきか？
→個人情報APIをPrivate APIと捉え、厳格な認証・認可を不要とすべき？
→ 個人情報APIを外部APIと捉え、厳格な認証・認可を必要とすべき？


エンドユーザー＝Resource Owner
APIを利用する側のサービス＝OAuth Client

・現行システム＝OAuth Client
・個人情報API＝Resource Server
・Akamai／管理サイトログイン機能＝Authorization Server


構成、捉え方

・構成全体で1つのシステムと捉え、現＋新で補完し、GDPR要件充足を目指す
※前提：直接個人情報APIを呼び出すルートがない事
⚫︎認証・認可
→入口（現行側）でユーザ毎の認証・認可は行っている
→個人情報APIはその内の内部処理、と捉える
＝
▲ログ追跡性（5W1H）
→現行側ログは、GDPRが求めるレベルのログ出力はされているか？（現行チームに対応依頼？）
→個人情報API側だけで、現行側での操作内容のログ出力は不可能
→個人情報API内部での操作内容はログ出力するよう設計可能

・個人情報 API（API単体+新側インフラ）のみをFJスコープと捉え、GDPR要件充足を目指す
※前提：直接個人情報APIを呼び出すルートがあっても問題ない
▲認証・認可
→現行とは別途、ユーザ毎の認証・認可すべき？
⚪︎ログ追跡性（5W1H）
→個人情報API内部での操作内容はログ出力するよう設計可能

・個人情報 API（API単体+新側インフラ）のみをFJスコープと捉えるが、Private APIである為、新側での厳格な認証・認可までは不要とする

ログ（追跡性）
・システム全体の追跡性
・個人情報に絞った追跡性

認証・認可（機密性、アクセス制御）
・現行FCサイト
→Akamai
・現行管理サイト
→どのようにログイン認証・認可管理しているか整理中
・現行バッチ
→バッチ実行ユーザの操作として扱っている？
・現行業務担当者作業
→検討対象外（新構成ではこのルートは用意しない為）

データ保護（完全性）

匿名化

押さえておきたい基礎知識！情報セキュリティの3要素とは
https://www.fujitsu.com/jp/solutions/business-technology/security/secure/column/201703-1/

「機密性」は限られた人だけが情報に接触できるように制限をかけること。
「完全性」は不正な改ざんなどから保護すること。
「可用性」は利用者が必要なときに安全にアクセスできる環境であることです。



※FC会員、業務管理者、バッチ以外のアクターで個人情報APIを実行し得るアクターは？

※FCサイト/管理サイト/バッチで認証・認可方式を区別すべき？それぞれで適切な方式は？
・FCサイト→Akamai OIDC？
・管理サイト→ID/パスワード認証（クライアント単位ACL）？
・バッチ→ID/パスワード認証（クライアント単位ACL）？
↑かつ、すべてでTLSクライアント認証



セキュリティガイドライン


WEB APIでの認証方式
▫️ID/パスワード認証（BASIC認証など）
→ユーザ（or任意のACL単位）情報の管理が必要
→低セキュリティレベル（+HTTPSが好ましい）
⚫︎ACL→任意の単位

▫️APIキー認証
→APIキーの管理が必要（KMSは？）
→低セキュリティレベル（+シークレット可？）
⚫︎ACL→任意の単位
⚫︎API Gatewayならキーの管理は容易（ECSとの連携は…？）

▫️トークン認証
Bearer認証
OAuth2.0認証
OpenID Connect認証
SAML認証
AWS Cognite？
★Akamai？（+管理サイトは別途…）
→認可サーバ（認証・トークン払い出しなどの管理API）or外部IdPが必要
→ユーザ情報の管理が必要
▲ACL→ユーザ単位（共用不可）

▫️TLSクライアント認証
→サーバ証明書の管理が必要
→クライアント証明書の管理が必要
⚫︎高セキュリティレベル
▲ACL→不可
★別認証と組み合わせることでACL可

OAuth 2.0 クライアント認証
https://qiita.com/TakahikoKawasaki/items/63ed4a9d8d6e5109e401

世界一わかりみの深いOAuth入門
https://tech-lab.sios.jp/archives/25470

★OAuth 2.0＆OpenID Connectユースケースと関連仕様まとめ
https://www.buildinsider.net/enterprise/openid/oauth20

★ Akamai
https://janrain-education-center.knowledgeowl.com/home/an-introduction-to-oauth-20-and-openid-connect

ACL（認可）

機能要件
FCサイト
・未登録会員→自身のPOSTのみ？
・FC会員→自身のみ★
管理サイト
・業務管理者→全ユーザ
・システム管理者→全ユーザ（匿名化？）
バッチ
・→全ユーザ？


法令（GDPR）的要件

4A+E対策

A1: 認証(Authentication)の厳格化: アクセス者の特定
● 共用アカウントの利用の原則禁止

A2: 認可(Authorization)の厳格化: アクセス権の最少化
● ロール・ベース・アクセス制御による認可の運用

A3: 管理(Administration)の厳格化: 認証と認可の適切な維持
● 管理作業の定型化ツールによる運用
● 特権アカウントの運用時凍結

A4: 監査(Audit)の厳格化: 認証・認可・管理の証跡の保全
● 追記と読み出しだけに限定し、運用から独立した保全
● アノマリアクセスの監視

E : データ自身の保護:暗号化(Encryption)
● データアクセス経路の遮断/データファイルの暗号化