GitHub Workflow permissions
GitHub ActionsのワークフローやJobでGITHUB_TOKENへ与える権限を定める設定。必要な読み取り・書き込み操作を絞り、同じJob内の外部Actionにも過剰な権限を渡さないようにする。
詳細を見る →CVE、EDR、OAuth、SBOMなど、サイバーセキュリティ用語の意味を日本語で解説。検索・カテゴリ・難易度で絞り込めます。
全1182語のうち 901〜960語を表示しています。全件横断はサイト内検索を利用できます。
このページの表示範囲では、条件に合う用語がありません。 入力したキーワードで全件を検索する
GitHub ActionsのワークフローやJobでGITHUB_TOKENへ与える権限を定める設定。必要な読み取り・書き込み操作を絞り、同じJob内の外部Actionにも過剰な権限を渡さないようにする。
詳細を見る →デジタルフォレンジックで、電源断や時間経過によって失われやすい情報から先に取得するため、メモリ、通信状態、ディスクなどの証拠を優先順に整理する考え方。
詳細を見る →許可された者だけが情報にアクセスできる性質。暗号化・アクセス制御・認証などの手段で実現する。CIA三原則のC。
詳細を見る →CDN等の共有HTTPキャッシュに対する応答の最大経過秒数を定める指令。共有側ではmax-age等より優先され、利用者のブラウザ用の鮮度と別の期間を設定できる。
詳細を見る →HTTP応答をキャッシュへ保存することは許し、再利用前に配信元での成功した検証を要求する指令。名前に反して保存禁止を意味せず、機密データの保存制御と区別して使う。
詳細を見る →HTTPキャッシュに要求・応答を保存させないための指令。機密情報を含む応答の保存を制限する際に使い、保存は許すが再利用前の検証を要求するno-cacheとは異なる。
詳細を見る →HTTP応答を共有キャッシュに保存させず、利用者側の私的キャッシュでは保存を許す指令。CDN等による共有とブラウザ内の保存を分けるもので、すべての保存禁止ではない。
詳細を見る →HTTP応答が新鮮とみなされる最大の経過秒数を示す指令。ブラウザ等が再利用できる期間に関係し、ログインセッションや認証トークンの有効期限を設定するものではない。
詳細を見る →共通する標的や目的を持ち、特定の期間に行われた一連の侵入活動をまとめて追跡するための分析単位。
詳細を見る →システムや情報に損害を与える可能性のある事象・行為・主体。自然災害・内部不正・外部攻撃者・マルウェアなどが含まれる。リスク = 脅威 × 脆弱性 × 影響。
詳細を見る →サイバー上の有害な活動を実行・支援する個人、集団、組織などを指す一般的な呼称。動機、能力、関係性は証拠と確度を分けて扱う。
詳細を見る →攻撃者のTTP(戦術・技術・手順)・IOC(侵害の痕跡)・脅威アクターに関する情報。防御策の優先付けや検知ルール改善に活用する。STIX/TAXIIでデータ交換が標準化されている。
詳細を見る →複数の情報源から脅威情報を収集・正規化・関連付けし、IOCの評価、共有、検知製品への連携や対応判断を支援するための運用基盤。
詳細を見る →想定する脅威の行動や技術を、許可された検証環境で安全に模擬し、ログ収集、検知、対応手順が期待どおり機能するかを確認する活動。
詳細を見る →アラートや観測値へ、出典、初出・最終確認日、関連する脅威、確度、共有制限などの脅威情報を付加し、判断材料を増やす処理。
詳細を見る →アラートを待つのではなく、仮説に基づいて能動的に侵害の痕跡を探す防御活動。「すでに侵入されているかもしれない」という前提で、ログ・テレメトリーを横断的に調査し、未検知の攻撃や潜伏を発見する。
詳細を見る →データベースの表に対し、利用者や条件ごとに参照・変更できる行を制限する仕組み。同じ表に複数の顧客データを置く場合などに、アプリ側の絞り込みを補う。
詳細を見る →データを保管サービスへ送る前に、利用側のアプリケーションなどで暗号化する方式。サービス側で保存時に暗号化する方式と異なり、復号処理や鍵管理を利用側で設計する必要がある。
詳細を見る →クラウド環境で禁止事項、必須設定、検知条件を組織横断で適用し、利用者の自由度を残しながら危険な構成や逸脱を予防・発見する統制。
詳細を見る →AWS CloudTrailで、S3オブジェクトへのアクセスなどデータに対する操作を記録するイベント区分。リソースの設定変更を扱う管理イベントとは異なり、収集対象の設定を確認する必要がある。
詳細を見る →突然電源が失われた時点に相当する、ディスク上の状態としての整合性。バックアップに未保存のメモリ内容は含まれず、復元後にアプリが回復処理を行うことがある。
詳細を見る →GraphQLで、型やフィールドなどスキーマの情報を問い合わせる仕組み。開発支援やツール連携に使うが、公開範囲は利用者とAPIの用途に応じて判断し、認可とは分けて設計する。
詳細を見る →GraphQLのフィールドや返却件数等から操作の処理費用を見積もり、許容範囲を判断する方法。要求数が少なくても高負荷になる操作を扱うため、リクエスト数の制限を補う。
詳細を見る →GraphQL等のデータ取得層で、複数の取得をまとめ、同じキーの取得をメモ化するために使うライブラリ。バックエンドへの細かな要求を減らすが、認可や顧客間の分離は別途設計する。
詳細を見る →GraphQLで、開発側が審査した操作文だけを実行できるようにする許可リスト方式。主に操作を事前に把握できる自社クライアント向けで、単なる操作文の保存とは区別する。
詳細を見る →GraphQLで、単一要求へまとめられた操作の数などに上限を設ける制御。複数の操作を受け付ける実装では、HTTP要求数だけでなくまとめられた処理量を制限する必要がある。
詳細を見る →GraphQLの応答でフィールドに別名を付ける仕組み。同じフィールドを異なる引数で取得する等の用途があり、API運用では別名で増えた処理件数も負荷制御へ反映する。
詳細を見る →GraphQLで取得・変更するフィールドについて、利用者の権限や対象データに応じて操作を許可する制御。ログイン済みであることやAPI入口の認証だけで全項目を許可しない。
詳細を見る →GraphQLの操作で、フィールドを入れ子にできる深さの上限を設ける制御。深い関連データの取得による負荷を抑えるが、浅い操作で大量の項目を取得する負荷は別に評価する。
詳細を見る →GraphQLで一覧の返却を複数回へ分割し、一度に扱う項目数を制限する設計。レスポンスやバックエンドの負荷を抑える助けになるが、指定件数にサーバー側の上限が必要になる。
詳細を見る →GraphQLの操作文を保存し、識別子等で参照できるようにする方式。送信量削減等に使うが、保存しただけで操作が安全と審査済みになったり、未登録操作が禁止されたりするとは限らない。
詳細を見る →ブラウザへ、サイトに関連するキャッシュ、Cookie、ストレージ等の指定したデータを消去するよう伝えるHTTPヘッダー。サーバー側セッションの失効や漏えい済みデータの回収とは異なる。
詳細を見る →メールや文書内のリンクを利用者が開く時点で再評価し、配信後に悪性化したURLを含め、最新の判定で警告・遮断する防御機能。
詳細を見る →被害者のコンピュータを無断で使って暗号資産(Moneroなど)をマイニングさせる攻撃。ブラウザのJavaScript・マルウェア経由で感染し、CPU/GPUを占有するためシステムが著しく遅くなる。
詳細を見る →パスワード、APIキー、証明書などの認証情報を計画的または緊急に更新し、旧資格情報を失効させる運用。
詳細を見る →稼働環境とは別のクラウドアカウントへバックアップのコピーを保管する構成。同一アカウントの誤操作や権限侵害への備えになるが、管理権限や暗号鍵も分離して評価する必要がある。
詳細を見る →ログイン時の一度だけで信頼を固定せず、セッション中の端末状態、利用状況、リスク変化を評価し、必要に応じて再認証やセッション失効を行う考え方。
詳細を見る →端末状態やセッション、資格情報などの変化を共有し、サービスがアクセス継続可否を速やかに再評価できるOpenID Shared Signalsのプロファイル。
詳細を見る →AWS KMSの暗号操作に付加する、秘密ではないキーと値の組。暗号文と利用文脈を結び付けたり、鍵利用の許可条件に用いたりできるが、機密データの保管場所ではない。
詳細を見る →AWS KMSキーの利用を、特定の主体・操作・制約の範囲で許可する仕組み。鍵ポリシーとは別の許可経路になり、AWSサービスとの連携などで使われる。
詳細を見る →入力となる秘密情報から、必要な長さや用途の暗号鍵を導出する関数の総称。パスワード向けと、十分なエントロピーを持つ共有秘密向けでは、選ぶ方式や要求が異なる。
詳細を見る →低い権限でシステムに侵入した攻撃者が、OSやアプリの脆弱性・設定ミスを悪用して管理者権限を得るプロセス。垂直(一般→管理者)と水平(他ユーザーへ)の2種類がある。
詳細を見る →発行者が主張する属性や資格をデジタル署名などで表現し、受け取った検証者が発行元と改ざんの有無を機械的に確認できるデジタル資格情報。
詳細を見る →想定した事象に対して必要なログが生成・収集され、検知ルールが意図した条件で発火し、担当者が調査できる情報を受け取れるかを確かめる活動。
詳細を見る →アラートが示す事象と実際の脅威との対応がどれほど確かで、調査に必要な文脈や証拠を伴っているかを表す検知品質の考え方。
詳細を見る →業務環境の正常動作と検知対象を比較し、条件、しきい値、除外、文脈情報を見直して、検知漏れと誤検知のバランスを改善する作業。
詳細を見る →イベントの生成、収集、変換、保存、分析、アラート通知、調査までをつなぎ、検知を実務で利用可能にする一連の処理経路。
詳細を見る →特定の攻撃者像や公開された行動パターンをモデル化し、許可された範囲で一連の行動を模擬して、防御の検知・対応能力を評価する活動。
詳細を見る →Office、スクリプト、メール、資格情報などで悪用されやすい挙動をルール単位で監査または遮断し、Windows端末の攻撃経路を減らす防御機能。
詳細を見る →利用者、端末、アプリケーションなどの行動パターンを時系列で分析し、通常と異なる変化や複数の弱い兆候を見つける手法。
詳細を見る →実際には問題のない事象のうち、検知ルールや分析モデルが誤って異常・攻撃として判定した割合。検知運用の負荷と信頼性を評価する指標の一つ。
詳細を見る →コンテナ内のプロセスが、ランタイムやカーネルの脆弱性、過剰な権限、危険なマウントなどを通じて分離境界を越え、ホストや他コンテナへ影響する状態。
詳細を見る →文書や画像などからスクリプト、マクロ、埋め込みオブジェクト等の能動的要素を除去し、安全な構造へ再生成して利用者へ渡す防御技術。
詳細を見る →OAuthで、クライアント資格情報を秘密に保持する能力を持つクライアント。管理されたサーバー側で認証処理を行う構成などが該当し、資格情報の安全な管理が前提となる。
詳細を見る →信頼できる実行環境などを利用して、保存中・転送中だけでなく処理中のデータも隔離・保護し、基盤管理者を含む他の主体からのアクセスを制限する技術領域。
詳細を見る →クラウドサービスの構成、接続先、依存関係、データフローとデータ分類を整理するサービスの部品表。CycloneDXではSaaSBOMとして表現できる。
詳細を見る →ユーザーやプロセスには、タスク遂行に必要な最低限の権限のみを付与するセキュリティ原則。権限昇格攻撃の被害範囲を最小化するために重要。
詳細を見る →主アプリと同じPod内で動作し、ログ転送、プロキシ、設定更新などの補助機能を提供するコンテナ。ライフサイクルとネットワーク名前空間を共有する。
詳細を見る →攻撃者行動を検知する分析について、仮説、必要データ、ATT&CKとの対応、疑似コード、テストなどを公開するMITREの知識リポジトリ。
詳細を見る →重大なサイバー事象が事業継続、顧客、社会的信頼へ及ぼす影響を抑えるため、技術対応と経営判断、法務、広報、外部連携を統合して進める活動。
詳細を見る →