製品
Aikido Platform

包括的なセキュリティ司令塔

小さな白い点が均等に配置されたグリッド状の模様を持つ抽象的な黒い背景。

プラットフォームについて詳しく見る

開発者向けに構築された、高度な AppSec スイート。

  • 依存関係 (SCA)
  • SAST & AI SAST
  • IaC
  • AIコード品質
  • 機密事項
  • マルウェア
  • ライセンス (SBOM)
  • 時代遅れのソフトウェア
  • コンテナ画像

リアルタイムの可視性を備えた統合クラウドセキュリティ。

  • CSPM
  • 仮想マシン
  • Infrastructure as Code
  • クラウド検索
  • コンテナ&K8sスキャン
  • 強化されたイメージ。

AIを活用した攻撃的セキュリティテスト。

  • 継続的ペネトレーションテスト
  • ペンテスト
    新しい
  • バグバウンティ検証
  • DAST
  • アタックサーフェス
  • APIスキャン

アプリ内ランタイム防御および脅威検出。

  • ランタイム保護
  • AIモニタリング
  • ボット保護
  • Safe Chain
新機能: 人間を凌駕するAikidoのペンテスト。
さらに詳しく
ソリューション
機能別
AI 自動修正機能
CI/CD セキュリティ
IDEインテグレーション
オンプレミススキャン
継続的ペネトレーションテスト
新しい
ユースケース別
ペンテスト
新着
コンプライアンス
脆弱性管理
SBOMの生成
ASPM
CSPM
AikidoのAI
ブロック0日
ステージ別
スタートアップ
企業
業界別
フィンテック
ヘルステック
HRテック
リーガルテック
グループ会社
エージェンシー
モバイルアプリ
製造業
公共部門
銀行
Telecom
新機能: 人間を凌駕するAikidoのペンテスト。
さらに詳しく
ソリューション
使用例
コンプライアンス
SOC 2、ISO、その他の自動化
脆弱性管理
オールインワンの脆弱性管理
コード保護
高度なコード・セキュリティ
SBOMの生成
1クリック SCAレポート
ASPM
包括的なアプリケーションセキュリティ
CSPM
エンドツーエンドのクラウドセキュリティ
AikidoのAI
AikidoのAIに任せる
ブロック0日
被害を受ける前に脅威を遮断する
産業別
フィンテック
ヘルステック
HRテック
リーガルテック
グループ会社
エージェンシー
スタートアップ企業
企業
モバイルアプリ
製造業
公共部門
銀行
リソース
開発者
資料
Aikidoの使い方
公開APIドキュメント
Aikido 開発者ハブ
変更履歴
出荷状況を見る
レポート
調査、知見、ガイド
トラストセンター
安全、プライベート、コンプライアンス
オープンソース
Aikido インテル
マルウェア&OSS脅威フィード
禅
アプリ内ファイアウォール保護
丸い四角の中に、接続されたネットワークシンボルを持つ地球のアイコン。
OpenGrep
コード解析エンジン
Aikido Safe Chain
インストール時のマルウェアを防止します。
会社概要
ブログ
インサイト、アップデートなどを受け取る
顧客
最高のチームからの信頼
AIレポートの現状
450人のCISOと開発者からの洞察
イベント&ウェビナー
セッション、ミートアップ、イベント
レポート
業界レポート、調査、分析
Aikido 脅威インテリジェンス

リアルタイムのマルウェアおよび脆弱性脅威

小さな白い点が均等に配置されたグリッド状の模様を持つ抽象的な黒い背景。

フィードへ移動

インテグレーション
IDE
CI/CDシステム
クラウド
Gitシステムズ
コンプライアンス
メッセンジャー
タスクマネージャー
その他の統合
会社概要
会社概要
会社概要
チーム紹介
採用情報
募集中
プレスリリース
ブランドアセットのダウンロード
イベント
また会えますか?
オープンソース
OSSプロジェクト
お客様のフィードバック
最高のチームからの信頼
パートナープログラム
パートナー制度
価格お問い合わせ
ログイン
無料で始める
CC不要
Aikido
メニュー
Aikido
EN
EN
FR
JP
DE
PT
ES
ログイン
無料で始める
CC不要
学ぶ
/
コンプライアンスフレームワークハブ
/
第1章第2章第3章

NIST SP 800-53

4分で読めます70

次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター

要約

NIST 800-53は、米国連邦政府のセキュリティおよびプライバシー管理策に関する標準であり、政府機関や請負業者によって使用される膨大なカタログ(1,000以上の管理策)です。

アクセス制御、監査ロギング、サプライチェーンリスクなどをカバーします。

高度な保証が求められる環境(例:FedRAMP)向けに構築されており、容易ではありません。詳細なドキュメント、カスタマイズ、継続的な監視が求められます。

NIST SP 800-53 スコアカード概要:

  • 開発者の労力: 高い(多数の特定の技術的管理策の実装、変更管理のような厳格なプロセスへの準拠、広範な文書化、および厳格な評価への参加が必要です)。
  • ツール費用: 高い(SAST、DAST、SCA、SIEM、IAM、構成管理など、多くのドメインにわたる包括的なセキュリティツールが必要。さらにGRC/コンプライアンス管理プラットフォームも必要となることが多い)。
  • 市場への影響: 非常に重要(米国連邦機関に義務付けられています。多くの政府請負業者やCSPにとってFedRAMPを介して不可欠です)。非常に影響力がありますが、ISO 27001と比較して、米国の連邦政府以外の領域では直接的な関連性は低いです。
  • 柔軟性: 中程度(ベースラインとテーラリングガイダンスを提供しますが、管理策のセット自体は広範かつ具体的です)。
  • 監査の厳格度: 非常に高(数百の管理策に対する厳格な評価、詳細な証拠、ATOのような正式な承認プロセスが必要です)。

NIST SP 800-53とは何ですか?

NIST Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizationsは、米国国立標準技術研究所(NIST)の主要な出版物です。その主な目的は、連邦政府の情報システムおよび組織を保護するために設計された、セキュリティおよびプライバシー管理策の包括的なカタログを提供することです。これは、連邦政府機関がFISMAの下でサイバーセキュリティリスクを管理するために使用するリスク管理フレームワーク(RMF)の核となる部分を形成します。

NIST 800-53(現行リビジョン5)の主な特徴:

  • 包括的なコントロールカタログ: セキュリティとプライバシーの技術的、運用的、管理的な側面をカバーする、20のファミリーに分類された1,000以上の特定のコントロールが含まれています。例として、アクセス制御(AC)、インシデント対応(IR)、システムおよび情報整合性(SI)、構成管理(CM)、サプライチェーンリスク管理(SR)などがあります。
  • リスクベースアプローチ: 実装は、機密性、完全性、または可用性が侵害された場合の潜在的な影響(低、中、高)に基づいて情報システムを分類することから開始します(FIPS 199およびNIST SP 800-60を使用)。
  • 管理ベースライン: 低、中、高影響度システム向けに、事前定義された管理策の初期セット(ベースライン)を提供します。
  • 調整: 組織は、特定のミッションニーズ、環境、およびリスク評価に基づいて、ベースライン管理策を追加、削除、または変更して調整することが求められます。
  • プライバシーの統合:リビジョン5では、プライバシーコントロールがセキュリティコントロールと並行して大幅に統合され、統一されたカタログとなっています。
  • 実装と評価への注力: 管理策自体を詳細に説明し、その有効性を評価するためのガイダンスを提供します。

NIST CSFが「何をすべきか」(特定、保護などの機能)を提供する一方で、NIST 800-53は、広範なコントロールリストを通じて詳細な「どのようにすべきか」を提供します。これは、NIST CSFやNIST SP 800-171(連邦政府以外のCUIを扱うシステム向けの800-53の大部分のサブセット)を含む、他の多くの標準やフレームワークによって参照されるソースカタログです。

なぜそれが重要なのか

NIST 800-53は、以下の点において極めて重要です。

  • 米国連邦機関: FISMAに基づき、連邦情報システムを保護するための必須の基盤です。
  • Government Contractors: 連邦機関にサービスやシステムを提供する企業は、契約の一部として、NIST 800-53の管理策(またはNIST SP 800-171やCMMCなどの関連規格)への準拠を実証する必要があることがよくあります。
  • クラウドサービスプロバイダー(FedRAMP経由): 連邦政府機関での利用のためにCSPを承認する連邦リスクおよび認証管理プログラム(FedRAMP)は、そのセキュリティ要件をNIST 800-53に大きく依拠しています。
  • 高い保証を求める組織: 連邦要件外であっても、重要インフラの組織や非常に高いレベルのセキュリティ保証を求める組織は、その包括性と厳格さからNIST 800-53を採用することがよくあります。
  • 他の標準の基盤: その詳細な管理策の定義は広く参照され、世界中の他のセキュリティ標準やベストプラクティスに影響を与えています。

コンプライアンスは、厳格な連邦要件に準拠した、成熟し、十分に文書化された、包括的なセキュリティおよびプライバシープログラムを示します。

何を、どのように実装するか (技術的側面とポリシー側面)

NIST 800-53の実装は、多くの場合NISTリスク管理フレームワーク(RMF)によって導かれる、構造化された多段階のプロセスです。

  1. システムの分類(RMFステップ1): FIPS 199およびNIST SP 800-60を使用して、侵害の潜在的な影響に基づいて情報システムのセキュリティカテゴリ(低、中、高)を決定します。これは、ベースラインコントロールを決定するため、非常に重要です。
  2. 制御の選択(RMFステップ2): システムカテゴリに基づいて、適切なベースライン制御セット(低、中、高)を選択します。
  3. 管理策の調整: 組織のリスク評価、特定の技術、ミッションニーズ、および運用環境に基づいて、管理策を追加、削除、または変更することでベースラインを調整します。すべての調整決定を文書化します。
  4. コントロールの実装(RMFステップ3): 選択され、調整されたコントロールを導入します。これには、システムの構成、ポリシーと手順の確立、および該当する20のコントロールファミリーすべてにおける担当者のトレーニングが含まれます。
    • 技術的実装: ファイアウォールの設定 (SC-7)、暗号化メカニズムの実装 (SC-13)、最小特権の強制 (AC-6)、侵入検知システムの展開 (SI-4)、システム構成の安全な管理 (CMファミリー)、多要素認証の実装 (IA-2)、システムイベントのログ記録 (AUファミリー) など。
    • ポリシーと手順の開発: アクセス制御ポリシー (AC-1)、インシデント対応計画 (IR-1)、構成管理計画 (CM-1)、緊急時対応計画 (CP-1)、セキュリティ意識向上トレーニングプログラム (AT-1) などを文書化すること。
  5. 実装の文書化: システムセキュリティ計画(SSP)内で各コントロールがどのように実装されているかを徹底的に文書化します。これには、構成、ポリシー、手順、および責任者が含まれます。
  6. 管理策の評価(RMFステップ4): 管理策が正しく実装され、意図どおりに機能し、セキュリティ要件を満たすという望ましい結果を生み出していることを検証します。これには、厳格なテストと証拠収集が伴うことがよくあります。
  7. Authorize System (RMF Step 5): 評価結果と、不備に対する改善計画およびマイルストーン (POA&M) に基づき、認可担当者がリスクベースの決定を行い、運用認可 (ATO) を付与します。
  8. コントロールの監視 (RMF ステップ 6): コントロールの有効性を継続的に監視し、変更を文書化し、継続的な評価を実施し、システムのセキュリティ体制について報告します。

導入には多くのリソースが必要であり、相当な技術的専門知識、文書化の労力、および継続的な管理が求められます。

避けるべきよくある間違い

包括的なNIST 800-53フレームワークの実装は困難です。よくある間違いは次のとおりです。

  1. 不正確なシステム分類: 影響度レベルを過小評価すると、不適切な管理策ベースラインが選択され、重大なリスクが未対処のままになります。
  2. テイラリングの省略または不十分な文書化: 適切なテイラリングなしにベースライン制御を実装すること、または制御が変更された、あるいは適用不可と見なされた理由を文書化しないこと。
  3. リソース不足:数百ものコントロールを実装、文書化、評価、監視するために必要な多大な時間、予算、専門知識を過小評価していること。
  4. 不適切な文書化(SSPおよび証拠): 詳細なシステムセキュリティ計画を作成しない、または評価中に管理策が実装され効果的であることを証明する十分な証拠を収集しないこと。「文書化されていなければ、それは行われなかったことになります。」
  5. 一度限りのプロジェクトとして扱うこと: NIST 800-53への準拠には、継続的な監視、更新、再評価が必要です。継続的な取り組みがなければ、セキュリティ態勢は劣化します。
  6. 自動化の欠如: 数百または数千のコントロールにわたるコントロールの実装、評価、監視を手動で管理しようとすると、非常に非効率的でエラーが発生しやすくなります。
  7. 不適切な管理策の選定/解釈: 管理策の要件を誤って解釈したり、管理策の目的に実際には合致しない方法で実装したりすること。

監査人/評価者が尋ねること(開発者向け)

NIST 800-53コンプライアンス(多くの場合FISMAまたはFedRAMP向け)を検証する評価者は、開発に関連する特定のコントロールの実装証拠を調査します。

  • (SA-11) 開発者テストと評価: 「SDLC中に実施されるセキュリティテスト(静的解析、動的解析、脆弱性スキャン)のプロセスと証拠を提示してください。」
  • (SA-15) Development Process, Standards, and Tools: 「セキュアソフトウェア開発ライフサイクル(SSDLC)プロセスと使用されているツールのドキュメントを提示してください。」
  • (CM-3) 構成変更管理: 「承認とテストを含め、コードデプロイメントの変更管理プロセスについて説明してください。」
  • (SI-7) Software, Firmware, and Information Integrity: 「本番環境にデプロイされるソフトウェアの整合性をどのように確保していますか(例:コード署名、整合性チェック)?」
  • (AC-6) Least Privilege: 「異なる環境(開発、テスト、本番)における開発者のアクセスはどのように制御されていますか?」
  • (AU-2) Event Logging: 「アプリケーション内のセキュリティ関連イベントがログに記録されている証拠を提示してください。」
  • (RA-5) 脆弱性スキャン: 「アプリケーションおよびインフラストラクチャの最近の脆弱性スキャンレポートと、修正の証拠を提示してください。」
  • (SR-3) サプライチェーン管理とプロセス: 「ソフトウェアで使用されるサードパーティライブラリおよびコンポーネントに関連するセキュリティリスクをどのように評価し、管理していますか?」(SCAに関連)

評価者は、詳細な文書(ポリシー、手順、SSP)と具体的な証拠(ログ、スキャンレポート、構成、チケット)を要求し、各適用可能なコントロールが実装され、効果的であることを証明します。

開発チームのためのクイックウィン

NIST 800-53の完全な実装は複雑ですが、開発チームは主要な原則に沿って取り組み始めることができます。

  1. セキュアなSDLCを採用する: 開発プロセスを文書化し、SAST/SCAのようなセキュリティ活動を早期に統合し始めましょう。(SAファミリーに準拠)
  2. 脆弱性スキャンを自動化:SAST、DAST、SCA、およびIaCスキャンをCI/CDパイプラインに統合します。(RA-5、SA-11に準拠)
  3. 変更管理の実装: Gitブランチ戦略を活用し、PRのレビュー/承認を必須とし、デプロイメントを追跡します。(CM-3に準拠)
  4. シークレット管理: ハードコードされたシークレットを排除し、安全なボルトを使用します。(さまざまなAC、SIコントロールに準拠)
  5. ログの一元化: アプリケーションが主要なイベントを中央システムにログ記録するようにします。(AUファミリーに準拠)
  6. 依存関係管理:SCAツールを使用して、サードパーティライブラリの脆弱性を追跡および管理します。(SRファミリー、RA-5に準拠)

これを無視すると...(非準拠の結果)

NIST 800-53が関連する組織(特に連邦政府機関や請負業者)にとって、不遵守は深刻な結果をもたらします。

  • 連邦政府契約の喪失: NIST 800-53または関連規格(800-171、CMMC)に基づく契約要件を満たさない場合、契約の終了や新たな連邦政府ビジネスを獲得できない事態につながる可能性があります。
  • FISMA監査の失敗: 連邦機関は、FISMA監査に失敗した場合、議会の監視、予算削減の可能性、および風評被害に直面します。
  • FedRAMP ATOの取得不能: クラウドサービスは、NIST 800-53のベースラインを満たすFedRAMP Authorization to Operateがなければ、連邦政府機関によって使用することはできません。
  • セキュリティリスクの増大: 非準拠は、必要なセキュリティ制御が不足しているか、効果がない可能性が高いことを意味し、侵害や攻撃に対する脆弱性を大幅に高めます。
  • 法的および風評被害: 不遵守に起因する侵害は、訴訟、規制当局からの罰金(HIPAAのような他の法律が関与する場合)、および深刻な風評被害につながる可能性があります。

よくあるご質問

NIST 800-53は必須ですか?

米国連邦情報システム(国家安全保障システムを除く)には、FISMAの下で義務付けられています。連邦政府にサービスを提供する政府請負業者やクラウドプロバイダー(FedRAMP、CMMC、契約条項を介して)には、間接的に義務付けられることがよくあります。ほとんどの民間企業にとっては任意ですが、高保証のベンチマークと見なされています。

NIST 800-53とNIST Cybersecurity Framework (CSF)の違いは何ですか?

NIST CSFは、5つの主要機能(特定、保護、検知、対応、復旧)を中心に構造と共通言語を提供する、高レベルの任意のフレームワークです。NIST 800-53は、CSFの目標を実装するために使用される特定のセキュリティおよびプライバシーコントロールの詳細なカタログであり、特に連邦政府内で利用されます。CSFは「何をすべきか」であり、800-53は主に「どのようにすべきか」です。

NIST 800-53とNIST 800-171の違いは何ですか?

NIST 800-53は、連邦政府システム向けの包括的な管理策カタログです。NIST 800-171は、非連邦政府システム(例:請負業者のシステム)におけるControlled Unclassified Information (CUI) の保護に焦点を当てています。800-171の管理策は、主にNIST 800-53のModerateベースラインから派生していますが、広範なテーラリングガイダンスなしに要件として提示されています。

NIST 800-53認証はありますか?

いいえ、NISTは800-53コンプライアンスの直接的な認証を提供していません。コンプライアンスは通常、FISMA監査、FedRAMP認証プロセス、または契約上の要件の一環として実施される評価を通じて実証され、その結果、証明書ではなく運用承認(ATO)が発行されることがよくあります。

Low、Moderate、Highのベースラインとは何ですか?

これらは、セキュリティ侵害による潜在的な影響がLow、Moderate、またはHighと分類された(FIPS 199経由で)システムに推奨される、NIST 800-53カタログから事前に選択されたコントロールのセットです。影響レベルが高いほど、より多くのコントロールとより厳格な実装が求められます。

システムセキュリティプラン(SSP)とは何ですか?

SSPは、NIST 800-53(およびFedRAMPのような関連フレームワーク)によって要求される重要な文書です。情報システムの境界、その環境、および各必須セキュリティ管理策がどのように実装されているかについて詳細な説明を提供します。

NIST 800-53の最新バージョンは何ですか?

現在、最新バージョンはリビジョン5(Rev. 5)で、2020年9月に公開されました。これにより、コントロールが大幅に更新され、プライバシーが統合され、サプライチェーンリスク管理のような新しいファミリーが導入されました。

次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
次の章
前のチャプター
ジャンプ先:
テキストリンク

適切なセキュリティ対策。
25,000以上の組織から信頼されています。

無料で始める
CC不要
デモを予約する
共有:

www.aikido.dev/learn/software-security-tools/nist-800-53

目次

第1章:コンプライアンスフレームワークの理解

コンプライアンスフレームワークとは何か、なぜ重要なのか?
コンプライアンスフレームワークがDevSecOpsワークフローに与える影響
フレームワーク間の共通要素

第2章:主要なコンプライアンスフレームワークの解説

SOC 2コンプライアンス
ISO 27001
ISO 27017 / 27018
NIST SP 800-53
NIST SSDF (SP 800-218)
OWASP ASVS
GDPR
NIS2指令
DORA
EUサイバーレジリエンス法(CRA)
CMMC
PCI DSS
FedRAMP
HIPAA / HITECH
エッセンシャルエイト
シンガポール CCoP (CII向け)
日本のサイバーセキュリティ法および関連法規(APPI)

第3章:開発におけるコンプライアンスの実装

組織に適したフレームワークの選択
準拠したDevSecOpsパイプラインの構築
コンプライアンスに向けた開発チームのトレーニング
開発者向け監査準備
コンプライアンスの長期的な維持
終わり

関連ブログ記事

すべて表示
すべて表示
2026年1月5日
•
コンプライアンス

エンジニアリングチームとセキュリティチームがDORAの技術要件をどのように満たすことができるか

2025年12月3日
•
コンプライアンス

英国のサイバーセキュリティ・レジリエンス法案に準拠する方法:現代のエンジニアリングチームのための実践ガイド

2025年10月13日
•
コンプライアンス

Aikido + Secureframe:コンプライアンスデータを常に最新の状態に保つ

会社概要
  • プラットフォーム
  • 価格
  • 会社概要
  • 採用情報
  • お問い合わせ
  • パートナー制度
リソース
  • 資料
  • 公開APIドキュメント
  • 脆弱性データベース
  • ブログ
  • お客様のフィードバック
  • インテグレーション
  • 用語集
  • プレスリリース
  • カスタマーレビュー
産業別
  • ヘルステック
  • メドテック
  • フィンテック
  • セキュリティテック
  • リーガルテック
  • HRテック
  • エージェント向け
  • 企業向け
  • スタートアップ向け
  • PEおよびグループ会社向け
  • 政府・公共部門向け
  • スマートマニュファクチャリング&エンジニアリング向け
使用例
  • ペンテスト
  • コンプライアンス
  • SAST & DAST
  • ASPM
  • 脆弱性管理
  • SBOMの生成
  • WordPressセキュリティ
  • コード保護
  • Microsoft向けAikido
  • AWS向けAikido
比較する
  • 全ベンダーとの比較
  • vs Snyk
  • 対Wiz
  • vs Mend
  • vs オルカ・セキュリティ
  • vs Veracode
  • vs GitHubアドバンスドセキュリティ
  • vs GitLab Ultimate
  • vs Checkmarx
  • vs Semgrep
  • vs SonarQube
  • 対Black Duck
リーガル
  • プライバシーポリシー
  • クッキーポリシー
  • 利用規約
  • マスターサブスクリプション契約
  • データ処理契約
リンクする
  • hello@aikido.dev
セキュリティ
  • トラストセンター
  • セキュリティの概要
  • クッキー設定の変更
サブスクライブ
すべての最新情報を入手
LinkedInYouTubeX
© 2026 Aikido Security BV | BE0792914919
🇪🇺 Keizer Karelstraat 15, 9000, Ghent, Belgium
🇺🇸 95 Third St, 2nd Fl, San Francisco, CA 94103, US
🇬🇧 Unit 6.15 Runway East 18 Crucifix Ln, London SE1 3JW UK
SOC 2
コンプライアンス
ISO 27001
コンプライアンス
FedRAMP
導入