#Security セキュリティ脆弱性をカテゴライズするような脅威モデリングでの方法論 Microsoft Threat Modeling ToolではSTRIDEを利用していくつかの自動分析を行うことができる STRIDEは以下の頭文字を取ったもの Spoofing（なりすまし） ブルートフォース攻撃 Tampering（改ざん） インジェクション攻撃 マスアサインメント攻撃 Repudiation（否認） ログ・監査証跡の不足 デジタル署名の欠如 タイムスタンプの不備 Information Disclosure（情報漏洩） 過剰なデータ露出 不適切なインベントリ管理 Denial of Service（サービス拒否） DoS攻撃 Elevation of privilege（権限昇格） https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats#stride-model

#Security Cookieの属性の1つ JavaScriptのようなスクリプトからのCookieアクセスを無効にする

#Security Cookie属性の1つ HTTPS通信を強制する

#Security Cookie属性の1つ 同一生成元ポリシーを許可するレベル Strict Lax None の3段階がある

#Security #API Architecture 以下のような目的でAPIの使用回数を制限する、制限を超過した時はHTTPの場合一般に429エラーを返す処理 STRIDEにあるようなDenial of Service（サービス拒否）からアプリケーションを保護する カスケード障害の可能性を制限する リソースの使用量を測定し従量課金に利用できる レートリミットの実装アルゴリズムには以下のようなものがある 固定ウインドウ（Fixed window） 固定期間内の制限 スライディングウインドウ（Sliding window） 直近の期間内の制限 トークンバケット方式（Token bucket） 総リクエスト数（トークンのバケツ）を定義しリクエストごとにトークンが利用される。バケツは定期的に充填される リーキーバケット方式（Leaky bucket） リクエストが処理される速度は固定で、バケツから溢れ出るリクエストを漏れ（リーキー）として扱う APIゲートウェイを利用している場合、ゲートウェイに配置するとよい

#Security OWASP Foundationが発表するセキュリティ専門家によるトップ10に含まれるべき脆弱性リスト 定期的に更新されるため最新を追うべき https://owasp.org/www-project-top-ten/

Availability #Security データを利用可能な状態に保つこと。大幅な遅延や不正なシャットダウンを許さない

#Authentication #Security 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords

Fitness Function #API Architecture システムの品質特性を数量化可能な指標で評価する、システムの目標を一貫して保証するためにビルドパイプラインに組み込まれる それぞれの特性は以下のようにカテゴライズされる コード品質（Code Quality） レジリエンス（Resiliency） オブザーバビリティ（Observability） パフォーマンス（Performance） コンプライアンス（Compliance） セキュリティ（Security） 運用操作性（Operability） Fitness function-driven development | Thoughtworks

Multi Factor Authentication 多要素認証 #Security #Authentication

#Security #Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい（攻撃者が大量のアカウントをロック可能） ユーザー名の列挙が可能（存在するアカウントのみがロックされる） ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効

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

#Network #Security 通信の初期段階に公開鍵暗号によって共通鍵暗号の鍵交換を行い、以降の通信を共通鍵暗号によって行う鍵システム 公開鍵暗号の計算コストの高さの課題から最小限の利用に留めている

#Security 機密性(Confidentiality) 完全性(Integrity) 可用性(Availability) の頭文字を取ったセキュリティの3つの柱

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

Rivest-Shamir-Adleman #Security 公開鍵暗号方式のアルゴリズムの一種 現実的に解読できない素因数分解によって高い信頼性を持つ RFC 8017 - PKCS #1: RSA Cryptography Specifications Version

#Security メッセージ送信者によるデジタル署名と、受信者による署名検証によって メッセージの改竄がされていないこと（完全性） メッセージが本当に秘密鍵を保持する送信者からのものであること（否認防止） の2つを保証する

HyperText Transfer Protocol Secure #Network #Security HTTPをTLSによって暗号化した通信

#Security メッセージの完全性を示す数学的手法、暗にハッシュと呼ばれることもある 不可逆 ハッシュ化された文書は元の文書に戻せない 非相関 元の文書の小さな変更が、ハッシュ化された文書では大きな変更となる 一意 同じメッセージダイジェストを生成する2つの文書は数学的に存在しない 最も一般的な使用法は、パスワードの安全な保存である

認可 #Security

Threat Modeling #Security アプリケーションに影響を与える脅威、攻撃、脆弱性、対策を特定する技術 モデリング手法として5つのステップを繰り返すよう紹介している Defining security requirements. Creating an application diagram. Identifying threats. Mitigating threats. Validating that threats have been mitigated. https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

#Security #Authentication 簡単かつ安価にDV証明書を発行する認証局 https://letsencrypt.org/ja/

数値ライブラリで始める安全なプログラミング #Programming #Security #Scala Scala Matsuri 2024での発表 Spireライブラリを用いて安全な数値計算を行うテクニックを紹介している

rootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerのセキュリティベストプラクティスとして紹介されている Linux Capabilities Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント

#Security #Authentication ブルートフォース攻撃を軽減するための認証ロック機構。ユーザーが正常に認証された後、そのブラウザに発行される特別なCookie 従来のアカウントロックアウトと比較して以下の利点がある DoS攻撃に対して耐性がある IPアドレスではなくブラウザCookieを基準とするため予測可能で実装しやすい ボットネットや代理経由の攻撃に対応しやすい 認証リクエスト時に有効なDevice Cookieの有無を確認し、未信頼クライアント（Device Cookieなし）からの認証試行回数を記録してロックアウトを実施する 実装にはJWT、Redis/Memcachedによるロックリスト管理、HMAC署名による改ざん防止などが用いられる https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies

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

認証 #Security

#Security　#HTTP HTTPS利用サーバーに対してHTTPリクエストを行う、または暗号アルゴリズムを脆弱なもので指定することで攻撃を行う

#Security メッセージが送信または受信を攻撃者が否認した際に、否認できないように保証すること

Integrity #Security データを正確に管理する、不正な変更や削除を許さない

#Security 組織が当該ドメインを制御（domain validation）していることを認証局が証明するデジタル証明書

#Security #Authentication #Blog ブルートフォース攻撃を防ぐための対策をまとめたOWASP Communityの記事 主な対策方法 アカウントロックアウト機能（DoS攻撃に悪用されるリスクに注意） Device Cookies（デバイスごとの認証ロック機構、DoS攻撃に対して耐性がある） パスワード検証時の遅延追加 IPアドレスベースのレートリミット CAPTCHAの導入 複数の秘密の質問による認証強化 単一の技術では回避されやすいため、複数の対策を組み合わせることが重要 https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

#Programming #Security Scala言語の数値型ライブラリ。汎用的で高速かつ高精度な数値と、効率的な数値コードシンタックスを提供する。 Spire Introduction to Spire Numeric Programming in Scala with Spire JOTB19 - Numeric Programming with Spire by Lars Hupel

#Security #Authentication 総当たり攻撃。パスワードや暗号鍵などを、可能な組み合わせを全て試すことで解読を試みる攻撃手法 対策として以下のような方法がある 強力なパスワードポリシーの適用（zxcvbn-ts、Pwned Passwordsによる検証） アカウントロックアウト機能 レートリミットによるログイン試行回数の制限 MFAの導入 CAPTCHAの利用 https://www.ipa.go.jp/security/vuln/websecurity/brute-force.html

#Security HTTPレスポンスヘッダの一つ、Webサイトが常にHTTPSを使用していることをWebブラウザに認識させる

Secret Management System #Security Secretの保存とアクセスを行うAPIを提供する、Secretをユーザが扱う段階では常に暗号化された状態になる

相互TLS認証 #Security #Network #TLS ネットワークの両端がTLS証明書を持ち相互に認証を行うことで、双方向で安全かつ信頼できることを保証する

#Security #Network TLSプロトコルにおいて、通信初期に公開鍵暗号方式によって通信を確立すること

Principle of Least Privilege #Security ユーザーやプロセスに対して、その役割を遂行するために必要な最小限の権限のみを付与する原則 不要な権限を排除することで攻撃面を削減し、セキュリティ侵害時の影響範囲を制限する

#Security miseのEnvironment機能における機密情報管理について、mise開発元のfnoxまたはsops, ageを用いて解決する方法 https://mise.jdx.dev/environments/secrets/

#TypeScript #Security #Authentication パスワード強度を検証するライブラリ https://github.com/zxcvbn-ts/zxcvbn

#Security シンプルでモダンな暗号化ツール、Go製 https://github.com/FiloSottile/age

#Security Kim Cameronが提唱したデジタルアイデンティティシステムの設計原則 アイデンティティメタシステムが満たすべき7つの法則： User Control and Consent（ユーザー制御と同意）: ユーザーがアイデンティティ情報の開示を制御できる Minimal Disclosure for a Constrained Use（最小限の開示）: 特定の目的に必要な最小限の情報のみを開示 Justifiable Parties（正当な当事者）: アイデンティティ情報は正当な目的を持つ当事者にのみ開示 Directed Identity（指向性アイデンティティ）: ユニバーサル識別子と方向性識別子の両方をサポート Pluralism of Operators and Technologies（多元性）: 複数のアイデンティティ技術とプロバイダーの共存 Human Integration（人間との統合）: ユーザーが理解し判断できるシステム設計 Consistent Experience Across Contexts（一貫した体験）: コンテキスト間で一貫したユーザー体験を提供 https://www.identityblog.com/?p=352

Secure Sockets Layer #Network #Security TLSの前身 基本的にはdeprecatedだが、デジタル証明書発行等の文脈で引き続き用いられている https://www.cloudflare.com/learning/ssl/what-is-ssl/

#Security #Authentication #OWASP HTTP Cookie https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

#Security #Authentication #OWASP Session Management zxcvbn-ts Pwned Passwords TLS Client Authentication MFA OAuth2 OpenId SAML Brute Force https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

#Security #OWASP DoS攻撃の防御戦略をまとめたOWASP Cheat Sheet Series OSIモデルに基づくCERT-EU分類を採用し、3つの攻撃層に分類している Application層：サーバリソースの枯渇またはアプリケーション機能の無効化（Slow HTTP攻撃など） Session/Protocol層：サーバやファイアウォール、ロードバランサーなどのリソース消費 Network/Volumetric層：ネットワーク帯域幅の飽和 主な防御戦略 単一障害点（SPOF）の排除と冗長性確保 グレースフルデグラデーション（部分的機能継続）の実装 入力検証（ファイルサイズ、リクエストサイズの上限設定） セッションタイムアウトの適切な設定 レートリミット（最小入信データレート、接続タイムアウト、帯域幅上限） ISPレベルでのIP偽装フィルタリング CPU集約的操作の回避 例外処理の適切な実装 静的リソースの別ドメイン配置 https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

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

PSS #Security #Kubernetes Podが満たすべきセキュリティ標準 3つのセキュリティプロファイルにグループ分けされており上から順に制限が厳しくなっていく Privileged Baseline Restricted Pod Security Standards | Kubernetes

#Kubernetes Pod定義にセキュリティ文脈の設定を追加するAPI 主にLinuxベースの以下のような観点に対する制御を行う Non-root User Linux Capabilities Configure a Security Context for a Pod or Container | Kubernetes

PSA #Security #Kubernetes Pod Security Standardsを違反する可能性がある際のアクションを実行する アクションは以下の3つ Warn Audit Enforce Pod Security Admission | Kubernetes

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

Denial of Service #Security リソース（サイト、アプリケーション、サーバー）を本来の目的で利用不可にすることを目的とした攻撃。C-I-Aの可用性を侵害する ネットワークパケット操作、プログラム脆弱性の悪用、リソース枯渇など多様な手段で実行される 主な攻撃手法 メモリ枯渇（ユーザー指定オブジェクト割り当て、セッションデータ過剰蓄積） CPU負荷増加（ループカウンター制御、バッファオーバーフロー） リソース解放失敗（ファイルロック、DB接続の未解放） アカウントロックアウト機構の悪用 ネットワーク帯域幅の飽和 対策としてレートリミット、入力検証、冗長性確保、グレースフルデグラデーションなどがある

#Network #Observability #Security #API Architecture マイクロサービスで行われるようなサービス間通信をルーティング、監視、保護する機能を提供する Kubernetesにおいてはクラスタ単位でサービスメッシュを構築する サービスメッシュはクラスタ内の全てのサービス間通信を制御するコントロールプレーンとコントロールプレーンで指定された作業が実行されるデータプレーン（サービス）の2つの基本要素を持つ。

#Security #Authentication ingressgatewayに対して、JWTの検証を行うためのカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/request_authentication/

#Security #Authentication Istioにおいてマイクロサービス間のmTLSを設定するカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/peer_authentication/

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

Completely Automated Public Turing test to tell Computers and Humans Apart #Security #Authentication 人間とボット（自動プログラム）を区別するための技術 主な目的はブルートフォース攻撃の防止、スパムやボットによる自動投稿の防止、不正なアカウント作成の防止 代表的な実装として、Google reCAPTCHA、hCaptcha、テキストベースCAPTCHAなどがある アクセシビリティの観点から、音声CAPTCHAなどの代替手段の提供が推奨される https://www.cloudflare.com/ja-jp/learning/bots/how-captchas-work/

#Security #Authentication 公開鍵と名前や住所等の識別情報を組み合わせることで、鍵の所有者を識別し正しい鍵であることを保証する証明書 認証局にデジタル署名をさせて発行される

Key Management System #Security 暗号化キーのディスカバリ、保存を行う管理システム。暗号化はKMS外で行う前提

#Security #Network HTTP通信において、セッション管理にいくつかのセキュリティ機能を提供する

#Security 公開鍵と秘密鍵の鍵ペアによって実現する暗号方式。名前の通り公開鍵は全世界に公開されるが秘密鍵は送信者受信者どちらかのみが知りうる鍵である 以下の2パターンによって暗号化、復号が行われる 送信者：公開鍵でメッセージを暗号化、受信者：秘密鍵で復号 可逆的：機密性、完全性、否認防止 送信者：秘密鍵でメッセージを暗号化、受信者：公開鍵で復号 デジタル署名/署名検証 不可逆的：完全性、否認防止

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

#Security メッセージの暗号化と複合に同じ鍵を使う暗号方式

Transport Layer Security #Network #Security 通信暗号化プロトコル ネットワーク通信開始時にTLSハンドシェイクによる通信の確立後、鍵交換を行いセキュアな通信を行う（ハイブリッド鍵システム） https://developer.mozilla.org/en-US/docs/Glossary/TLS

#Security 組織が法的に登録されたビジネスである（organization validation）ことを認証局が証明するデジタル証明書

Confidentiality #Security プライベートな情報を許可された方法のみで開示すること

Hash-based Message Authentication Code #Security 共通鍵とメッセージダイジェストによる共通鍵暗号方式 共通の鍵を有するので両者ともに署名付きトークンを生成・検証できる

#Security #完全性 #否認防止 デジタル署名されたメッセージを受信者が複合すること

主にDockerfileなどにおいて、非rootユーザーでのログインを推奨するセキュリティベストプラクティス Dockerfile ベストプラクティス docker-node/docs/BestPractices.md at main · nodejs/docker-node

Same Origin Policy #Security ホストドメインとポート番号が一致する場合にのみ、リソース間の相互交流を許可する

#Network #Security TLSによるHTTPS通信において、TLSハンドシェイクに用いるデジタル証明書のこと

#Network #Cloud Native #Observability #Security https://cilium.io/ eBPF技術を活用したクラウドネイティブなネットワーキングソフトウェア KubernetesのCNIとしてネットワークの接続、保護、監視を提供する ユースケースとして以下のような例がある L4 ロードバランシング https://cilium.io/use-cases/load-balancer/ kube-proxy https://cilium.io/use-cases/kube-proxy/ サービスメッシュ https://cilium.io/use-cases/service-mesh/ Gateway API https://cilium.io/use-cases/gateway-api/ Ingress https://cilium.io/use-cases/ingress/

#Security 2002年にAndre Durandが提唱した「Three Tiers of Identity」というフレームワーク。デジタルアイデンティティを3つの階層に分類する。 T1 - Personal Identity（個人アイデンティティ）: 時間を超えて不変で無条件。真の個人的デジタルアイデンティティであり、完全に本人が所有・管理し、本人の利益のためだけに存在する。 T2 - Corporate Identity（共有アイデンティティ）: 条件付きで一時的に割り当てられる。本人または発行した企業のいずれかによって取り消し可能。通常、ビジネス関係のコンテキストで本人を指す。 T3 - Marketing Identity（抽象化されたアイデンティティ）: 通常、人口統計やビジネスとのやり取りにおける行動に基づく。

JSON Web Token #Security #Authentication トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない 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)

CA #Security #Authentication 信頼されたデジタル証明書の発行者

#Security GitOpsの世界においてSecretをクライアントサイドで扱うGo製のツール。YAMLやJSONのファイル上でSecretを安全にgit管理することができる ageを用いたローカルでのキー管理か、KMSによるキー管理のどちらを選択できる CNCF sandbox project https://getsops.io/

#Security 脅威モデリングを行うためのツール群、Microsoftによって提供されている https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool

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

#Security DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Pervasive security

#Security OV証明書の内容に加えて、組織の情報と場所（extended validation）を認証局が証明するデジタル証明書

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

#Security Google Cloudが提供するSMS Secrets Store CSI Driverを用いてGKEに組み込み可能 Secret Manager の概要 | Secret Manager Documentation | Google Cloud

#Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud

Key Management Service #Security AWSが提供するKMS AWS Key Management Service