Role-based access control #Security/Authorization ロールごとに許可を定義する認可モデル これによりユーザーの部署異動等の際に即座に権限を変更できる

#Software Design #Cloud Native #Security/Authentication #Security/Authorization The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 #API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 #Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication / Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app

#Security/Authorization トークンを保持するBearer（持参人）が誰であれ、そのトークンをリソースへのアクセスに使うことができる 平文の文字列でシークレットや署名は扱わず、セキュリティはTLSのようなトランスポート層での仕組みに任せている HTTP通信のAuthorizationヘッダーに付与するのを推奨されている RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

#Security/Authentication #Security/Authorization DIDにおいて自己証明自律型識別子を提供する did:peer DIDメソッド定義 DIDドキュメント相当の情報をパブリックに公開しないため、安価でありセキュリティ強化に繋がる authorization セクションによる認可制御が可能 https://identity.foundation/peer-did-method-spec/

#Programming #Security/Authorization EffによるScala認可実装の話

#Security/Authorization Istioにおいてアプリケーション（L7）認可の役割を担うリソース KubernetesのCRDによって用意されており、Network policyに比べ柔軟でHTTP特有の設定が可能 Istio / Authorization Policy

#API Architecture #Security/Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー（Resource Owner） 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー（Resource Server） 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント（Client） リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー（Authorization Server） リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework

Identity Provider #Security/Authentication #Security/Authorization デジタルアイデンティティシステムにおいて、ユーザーの認証を行い、アイデンティティ情報を提供するサービスまたは組織 代表的なソーシャルIdPとして、Google、Facebook、GitHub、Microsoftなどがある OIDCやOAuth2プロトコルを用いてアイデンティティ情報を外部アプリケーションに提供する

#Security/Authorization 認可による保護対象

#Security/Authorization 主体とスコープとの紐付けをルールとして扱う

#Security/Authorization 保護対象のリソースに基づいて定める認可対象の機能範囲

Principal #Security/Authorization 認可チェックを受ける対象 ログインユーザーやAPIトークンなどがある

#Security/Authentication #Security/Authorization ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/

#Team Organization #Security/Authentication #Security/Authorization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する

Attiribute-based access control #Security/Authorization 従来のRBACに対し、リソースに割り当てられた属性（AWSではタグ）に基づいて許可を定義する認可モデル リクエスト元であるプリンシパルの属性がリソースの属性と一致した場合に操作を許可するポリシーを設計する ABAC 認証で属性に基づいてアクセス許可を定義する - AWS Identity and Access Management

#API Architecture #Network #Security/Authentication #Security/Authorization 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.

Insecure Direct Object Reference #Security/Authorization アクセス制御の不備により、URLやパラメータのID等を変更するだけで他のユーザーのデータにアクセスできてしまう脆弱性 OWASP Top Tenにおける代表的な脆弱性の一つで、Broken Access Controlの典型例 主な攻撃パターン URL操作: /user/123を/user/124に変更して他ユーザーの情報にアクセス リクエストボディ操作: POSTやPUTリクエストのID部分を改ざん ファイルアクセス: 静的ファイルのパス操作による機密情報の取得 対策として認可チェックの実装とUUIDのような推測困難なIDの利用が重要 https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html