webサービスの認可について色々調べてみた

導入

webサービスを開発するうえで、APIを提供することが一般的です。 多くの人に提供されますが、サービスによってはセキュリティ上、リソース制約上、または権限上の関係で一部APIに認証、認可を実装し、不正利用を低減させています。

認証と認可の違い

認証をAuthN、認可をAuthZとして区別することが提唱

• 認証（Authentication）は、接続したユーザの身元を確認するプロセス
  • パスワード、トークン、生体情報等
• 認可（Authorization）は、認証されたユーザがどの機能やデータにアクセスできるかを制御するプロセス
  • API側の実装等

API側の実装

API単独でやる場合はAPIごとに全ての処理を実装する必要あり(管理が複雑、冗長) 対策は以下

• API Gateway(TIS)
• OAuth 2.0

OAuth 2.0

認可サーバー（Authorization Server）を用意、認可サーバーはクライアントに「アクセストークン」という形で許可を与える。 具体的には以下

有名な手法

text

• RBAC(ロールベースのアクセス制御)
• ABAC(属性ベースのアクセス制御)

RBAC

• FLAT RBAC:各userには1つまたは複数のロールが割り当照られる
• HIERARCHICAL RBAC:上位権限を持つものは下位の権限も所有
• CONSTRAINED RBAC: 職務分離（SOD）が行われ、タスクを実施する権限を複数のユーザに分散
• SYMMETRIC RBAC : ユーザーとロールの関連性を確認できる機能（あるユーザーがどのロールに属しているか、あるロールにどのユーザーが割り当てられているかの確認）に加え、パーミッションとロールの関連性を確認できる機能

ABAC

認可のセキュリティチェック text