Security

TLS

Transport Layer Security #Network #Security HTTPSへの対応に用いられる暗号化プロトコルネットワーク通信時にTLSハンドシェイクによって鍵交換を行いセキュアな通信を行う

RBAC

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

RSA

#Security 秘密鍵と公開鍵による暗号方式署名に用いる際は公開鍵を用いて署名をした署名者のことを、秘密鍵によって署名付きトークンを検証できる RFC 8017 - PKCS #1: RSA Cryptography Specifications Version

Bearerトークン

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

JWT

JSON Web Token #Security トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空）それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっているヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いるペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

Basic認証

#Security HTTPプロトコルにおける認証方式ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う

HMAC

Hash-based Message Authentication Code #Security 共有秘密鍵と暗号化ハッシュ関数による暗号方式共有の鍵を有するので両者ともに署名付きトークンを生成・検証できる

Authorization to implement with Extensible Effect

#Security #Eff

Kubernetes Secret

#Cloud Infrastructure #Security KubernetesにおいてPodとは別に独立して機密情報を定義する具体的にはKubernetes Volumeにファイルとして置かれるケースがある Secret | Kubernetes

SHA

Secure Hash Algorithms #Security 電子署名の改竄防止等で最もよく利用されているハッシュ化アルゴリズム異なる元データから同一のハッシュ値が生成される可能性が低いことを求められ、SHA-2, SHA-256 等の種類がある RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)

OAuth徹底入門

ABAC

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