製品
コード、クラウド、ランタイムのセキュリティを確保するために必要なすべてを1つの集中管理システムで実現
コード
依存関係
オープンソースのリスクを防ぐ(SCA)
機密事項
暴露された秘密をキャッチ
SAST
記述通りの安全なコード
コンテナ画像
画像を簡単に保護
マルウェア
サプライチェーン攻撃の防止
コードとしてのインフラ
IaCの設定ミスをスキャンする
ライセンス・リスクとSBOM
リスクを回避し、コンプライアンスを遵守する
時代遅れのソフトウェア
EOLランタイムを知る
クラウド
クラウド / CSPM
ミスコンフィグ、エクスポージャ、リスクを修正する。
DAST
ブラックボックス・セキュリティ・テスト
APIスキャン
APIの脆弱性をテストする
仮想マシン
代理店なし、諸経費なし
ランタイム保護
アプリ内ファイアウォール / WAF
コード・クオリティ
まもなく
AIコード品質レビュー
自律的ペンテスト
まもなく
AIによる攻撃テスト
ディフェンス
特徴
AI 自動修正機能
Aikido AIによる1クリック修正
CI/CD セキュリティ
マージおよびデプロイ前のスキャン
IDEインテグレーション
コーディング中にすぐにフィードバックを得る
オンプレミスキャンニング
コンプライアンス優先のローカル・スキャン
ソリューション
使用例
コンプライアンス
SOC 2、ISO、その他の自動化
脆弱性管理
オールインワンの脆弱性管理
コード保護
高度なコード・セキュリティ
SBOMの生成
1クリック SCAレポート
ASPM
包括的なアプリケーションセキュリティ
CSPM
エンド・ツー・エンドのクラウドセキュリティ
AikidoのAI
AikidoのAIに任せる
ブロック0日
被害を受ける前に脅威を遮断する
産業別
フィンテック
ヘルステック
HRテック
リーガルテック
グループ会社
エージェンシー
スタートアップ企業
企業
モバイルアプリ
製造業
公共部門
価格
リソース
開発者
資料
Aikidoの使い方
公開APIドキュメント
Aikido 開発者ハブ
変更履歴
出荷状況を見る
セキュリティ
社内リサーチ
マルウェア&CVEインテリジェンス
トラストセンター
安全、プライベート、コンプライアンス
学ぶ
ソフトウェア・セキュリティ・アカデミー
学生
Aikido 無料体験
オープンソース
Aikido インテル
マルウェア&OSS脅威フィード
禅
アプリ内ファイアウォール保護
OpenGrep
コード解析エンジン
Aikido セーフチェーン
インストール中のマルウェアを防ぐ。
インテグレーション
IDE
CI/CDシステム
クラウド
Gitシステムズ
コンプライアンス
メッセンジャー
タスクマネージャー
その他の統合
について
について
について
チーム紹介
採用情報
募集中
プレスリリース
ブランドアセットのダウンロード
カレンダー
また会えますか?
オープンソース
OSSプロジェクト
お客様のフィードバック
最高のチームからの信頼
パートナープログラム
パートナー制度
ブログお問い合わせ
ログイン
無料で始める
CC不要
Aikido
メニュー
Aikido
EN
EN
FR
JP
DE
PT
ログイン
無料で始める
CC不要
学ぶ
/
コンプライアンス・フレームワーク・ハブ
/
第1章第2章第3章

ISO 27001

5分50

次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章

TL;DR 

ISO 27001は、情報セキュリティリスクを管理するための世界標準規格である。スコーピング、リスクアセスメント、附属書Aの管理、監査など、安全なISMSを構築し維持する方法を定義している。

SOC 2よりもプロセスが多いが、対象範囲は広い。国際的に事業を展開する場合や、拡張性のあるリスクベースのセキュリティフレームワークを求める場合には不可欠。

ISO 27001スコアカードの概要:

  • 開発者の労力:中程度から高程度(安全な SDLC ポリシーの遵守、リスクアセスメントへの参加、A.12/A.14 のようなコントロールの証拠の提出が必要)。
  • ツール費用:中程度から高い(監査費用が大きい、潜在的なISMSソフトウェア、セキュリティツール)。
  • 市場への影響非常に高い(世界的に認知された基準、国際ビジネス、規制産業、大企業にとって重要)。
  • 柔軟性:高い(フレームワークアプローチ、SoAを通じたリスクに基づく統制の選択)。
  • 監査の強度:高(初回認証の第1段階および第2段階、年次サーベイランス審査、プロセスと文書化に重点)。

ISO 27001とは何か?

ISO/IEC 27001は、情報セキュリティに焦点を当てた主要な国際規格です。国際標準化機構(ISO)と国際電気標準会議(IEC)が共同で策定したもので、情報セキュリティマネジメントシステム(ISMS)を組織の中で確立、実施、維持し、継続的に改善するための要求事項を規定している。

ISMSは単なる技術的なツールの集合ではなく、企業の機密情報を安全に管理するための体系的なアプローチです。ISMSには、人、プロセス、技術が含まれる。中核となる考え方はリスク管理であり、脅威と脆弱性を特定し、リスクを評価し、許容可能なレベルまで軽減するための管理策を実施する。

ISO 27001の主な構成要素:

  • 条項4~10:これらは、組織の状況の理解、指導者のコミットメント、計画(リスクアセスメントと処置)、支援(資源、認識、文書化)、運用、パフォーマンス評価(モニタリング、内部監査、マネジメントレビュー)、改善というISMS自体の必須要件を定義している。
  • 付属文書A:これは、14の領域(ただし、2022年版では4つのテーマで93の統制に改訂された)にグループ化された114の情報セキュリティ統制の参考セットを提供するものである。組織は、適用可能性宣言書(Statement of Applicability:SoA)を通じて、リスクアセスメントの結果に基づいて、附属書Aから関連する管理策を選択する。すべての管理が必須というわけではなく、特定されたリスクに対処するために必要な管理のみが対象となる。

SOC 2が認証報告書となるのとは異なり、ISO 27001は外部監査(ステージ1およびステージ2)に合格すると正式な認証となります。この認証は通常3年間有効で、維持するためには毎年サーベイランス監査が必要です。

なぜ重要なのか?

ISO 27001認証は、特にグローバルに事業を展開するハイテク企業や機密データを扱う企業にとって、大きな重みを持つ:

  • 国際的な認知度情報セキュリティ管理の世界標準として最も広く認知されており、世界的な信頼性を高めている。
  • 包括的なセキュリティ管理:構造化されたリスクベースのアプローチを強制し、技術的な管理だけでなく、全体的なセキュリティ態勢を向上させる。
  • 顧客とパートナーの信頼:SOC 2と同様、セキュリティを真剣に考えていることを顧客やパートナーに示す強力なシグナルとなり、契約書やRFPで求められることも多い。
  • 法規制の遵守: ISO 27001ISMSの導入は、体系的なリスク管理を実証することで、さまざまな法律や規制(GDPRなど)の要件を満たすのに役立ちます。
  • 侵害リスクの低減:ISMSが適切に実施されることで、セキュリティ・インシデントの可能性と影響が明らかに減少する。例えば、トヨタはサイバー攻撃を受けて生産停止に直面したが、強固なISMSはそのような混乱を防ぐのに役立つ。
  • 組織とプロセスの改善:セキュリティの取り組みに構造をもたらし、責任を明確にし、セキュリティを意識する文化を醸成する。

SOC 2は、米国のSaaS顧客の要求によって推進されることが多いですが、ISO 27001は、セキュリティ管理システム全体について、より広範で国際的に認められた保証を提供します。

何をどのように実施するか(技術・政策)

ISO27001の導入は、ISMSとリスクマネジメントを中心とした構造化されたプロセスである:

  1. 範囲の定義:組織のどの部分、場所、資産、技術をISMSの対象とするかを明確に決定する。
  2. リーダーシップのコミットメント:トップマネジメントの賛同とリソースを得る。
  3. ポリシーを定義する:高レベルのセキュリティポリシー(情報セキュリティポリシー、利用ポリシーなど)を策定する。
  4. リスク評価:情報資産、脅威、脆弱性、既存のコントロールを特定する。リスクの可能性と影響を分析する。
  5. リスク処置:許容できないリスクを軽減するための管理策(主に付属書Aから)を選択する。これを適用可能性報告書(SoA)に文書化し、含まれる/除外される管理策を正当化する。
  6. コントロールを導入する: 選択した技術的および手続き的な管理を展開する。多くはSOC 2と重複するが ISO 27001 附属書Aには具体的なカタログが掲載されている:
    • A.5 情報セキュリティ方針:マネジメントの方向性。
    • A.6 情報セキュリティ組織:社内組織、モバイル機器、テレワーク。
    • A.7 人材セキュリティ:雇用前、雇用中、雇用後のセキュリティ責任。
    • A.8 資産管理:在庫、所有権、許容される使用、分類、メディアの取り扱い。
    • A.9 アクセス管理:ビジネス要件、ユーザーアクセス管理、ユーザーの責任、システム/アプリケーションアクセス。(RBAC、MFAなどを含む)。
    • A.10 暗号:暗号管理、鍵管理に関する方針。
    • A.11 物理的および環境的セキュリティ:安全なエリア、設備のセキュリティ
    • A.12 運用セキュリティ:手順、変更管理、マルウェア対策、バックアップ、ログ記録、監視、脆弱性管理。(SAST、SCA、パッチなどを含む)。
    • A.13 通信セキュリティ:ネットワークセキュリティ管理、情報転送。(ファイアウォール、転送中の暗号化を含む。)
    • A.14 システムの取得、開発、保守:開発におけるセキュリティ要件、安全な開発方針、テストデータのセキュリティ。(セキュアな SDLC の実践)
    • A.15 サプライヤーとの関係:サプライヤー契約におけるセキュリティ、サプライヤーサービスの監視。(ベンダー管理)
    • A.16 情報セキュリティインシデント管理:責任、対応、インシデントからの学習
    • A.17 事業継続マネジメントにおける情報セキュリティの側面:計画、実施、検証(災害復旧)
    • A.18 コンプライアンス:法的/契約上の要件の特定、知的財産権、プライバシー(個人情報保護)、情報セキュリティの見直し。
  7. トレーニングと意識向上:従業員に対して、ポリシーとセキュリティに関する責任を教育する。
  8. モニタリングとレビュー統制の有効性を継続的に監視し、内部監査を実施し、マネジメントレビューを行う。
  9. 継続的改善:モニタリング、監査、リスクの変化に基づいてISMSを更新する。

リスクを特定し、コントロールを確実に実施し、監視し、改善するためのプロセスであるマネジメント・システムに重点を置いている。

避けるべき一般的な間違い

ISO 27001を効果的に導入するということは、このような頻発するエラーを回避するということである:

  1. 不適切な範囲設定:ISMSの範囲が広すぎる(管理できない)、または狭すぎる(重要な資産/プロセスをカバーしていない)。現実的でリスクに焦点を当てたものであること。
  2. 経営陣のコミットメントの欠如:目に見えるリーダーシップの支援、リソース、事業目標への統合がないまま、ISO 27001を純粋にITプロジェクトとして扱うこと。
  3. 不十分なリスクアセスメント:表面的なリスクアセスメントを実施し、主要な資産、脅威、脆弱性を正確に特定しないため、効果的なコントロールの選択ができない。
  4. 附属書Aの "チェックボックス "アプローチ:附属書Aのコントロールを、アセスメントで特定された特定のリスクと関連付けることなく実施すること。コントロールはリスクを扱うべきである。
  5. 不十分な文書化:方針、手順、リスクアセスメント、SoA、統制運用の証拠を適切に文書化していない。監査人は証拠を必要とする。
  6. 継続的改善を忘れる:認証取得を最終目標とすること。ISO 27001では、継続的なモニタリング、内部監査、マネジメント・レビュー、ISMSの更新が義務付けられています。
  7. 人材不足:十分な時間、予算、専門知識を持たずに、すべての取り組みを一人の人間やチームに任せること。組織全体の取り組みである。

監査役が質問すること(開発者フォーカス)

ISO 27001の監査員は、管理システムと実施された管理の両方を見ます。開発チームは、次のような附属書Aの管理に関する質問に直面する可能性があります:

  • "安全な開発方針を示せ"(A.14.2.1)
  • 「要求事項の段階でセキュリティ要件を確実に特定する方法を教えてください。(A.14.1.1)
  • 「オープンソースライブラリの脆弱性管理のプロセスについて教えてください。(A.12.6.1「技術的な脆弱性管理」関連)
  • 「開発環境、テスト環境、本番環境はどのように分けられていますか?(a.12.1.4 / a.14.2.6)
  • 「最後のメジャーリリース前に実施したセキュリティテストの証拠を提示する。(a.14.2.8 / a.14.2.9)
  • "開発者のさまざまな環境へのアクセスコントロールはどのように管理していますか?"(A.9)
  • "試験データの取り扱いと保護の手順を示してください。"(A.14.3.1)
  • "配備前のコード変更はどのようにレビューされ、承認されますか?" (a.12.1.2 / a.14.2.3)(a.12.1.2 / a.14.2.3)

彼らはプロセスと 証拠を重視する。方針があるか、それに従っているか、それを証明できるか。

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

ISO 27001は広範囲に及ぶが、開発チームはこれらのステップで大きく貢献できる:

  1. SDLC を文書化する:テストと配備のステップを含めて、現在の開発プロセスを書き出してください。これは、A.14 の管理の基礎を形成します。
  2. SAST/SCAの実装:CI/CDパイプラインの早い段階で、自動化されたコードと依存性のスキャンを統合する。これはA.12とA.14の一部に対応する。
  3. コードレビューの公式化:PR にはレビューと承認が必要なようにしましょう。Gitプラットフォームでこれを追跡しましょう。(Addresses A.14.2 controls)
  4. 環境の分離:開発環境、テスト環境、プロダク ト環境を、異なる認証情報とネットワーク制御を使用して明確に分離する。(アドレス A.12.1.4)
  5. 秘密の管理:秘密保管庫を実装し、ハードコードされた秘密をスキャンする。(アドレス A.9 / A.12 / A.14 コントロール)
  6. 依存関係のパッチ適用:脆弱な依存関係を特定し、更新するプロセスを確立する。(アドレス A.12.6.1)

これを無視すれば...(失敗の結果)

ISO 27001の審査に落ちたり、規格を無視したりすると、次のような事態を招く可能性がある:

  • 認証の喪失:既存の認証は停止または撤回される可能性がある。
  • 契約上の罰則/損失:認証の取得や維持に失敗すると、契約に違反したり、入札、特に国際的な入札で失格となる可能性がある。
  • 風評被害:セキュリティ態勢が脆弱であることを示唆し、グローバルな顧客やパートナーとの信頼関係を損なう。
  • 審査精査の増加:認証機関は、今後のサーベイランス審査の頻度や強度を増やし、コストと労力を増やす可能性がある。
  • 規制上の問題:コンプライアンス違反は、法的または規制上のセキュリティ要件(GDPRなど)を満たしていないことを示す可能性がある。
  • 市場機会の喪失: ISO 27001が事実上の要件となっている市場やセクターに参入できない。

よくあるご質問

ISO 27001とSOC 2の違いは何ですか?

ISO 27001は、国際規格とリスク評価に基づいて、情報セキュリティマネジメントシステム(ISMS)全体を認証します。SOC 2 は、主に米国市場のニーズに基づき、特定のサービスコミットメント(Trust Services Criteria)に関連するコントロールに関する認証レポートを提供します。両者は、多くの場合、コントロールが重複していますが、アプローチ、範囲、結果(認証と報告書)は異なります。

ISO 27001は必須か?

いいえ、一般的には自主的な基準ですが、特定の規制産業や国際市場で事業を展開するためには、契約上の要求事項であったり、必要であったりすることがよくあります。

ISO 27001認証にはどれくらいの期間がかかりますか?

実施には、成熟度によって6~12カ月、あるいはそれ以上かかることもある。認証プロセス(ステージ1およびステージ2審査)は次のとおりである。既存のISMSは、認証審査までに約6ヶ月の運用が必要です。

ISO 27001のコストは?

多額の投資が必要である。3年サイクルの監査費用は数万ユーロ/ドルになることもあり、それに加えて社内リソース、潜在的なコンサルティング、ツールのコストがかかる。中小企業の場合、監査費用だけで3年間で15,000ユーロ以上というのが大まかな見積もりかもしれない。

附属書Aの114項目(または93項目)すべてを実施する必要があるか?

いいえ。リスクアセスメントと治療計画に基づいて、各コントロールを適用声明書(SoA)に含めるか除外するかを正当化する必要があります。

認証の有効期間は?

通常は3年間だが、その間の有効性を維持するためには、毎年のサーベイランス審査に合格しなければならない。3年経過後は再認証審査が必要となる。

誰が監査を行うのか?

認定された独立した外部認証機関。内部監査も必要だが、認証にはつながらない。

次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
ジャンプする
テキストリンク


25k以上の組織から信頼されている。

無料で始める
CC不要
デモを予約する
シェアする

www.aikido.dev/learn/software-security-tools/iso-27001

目次

第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)
コンピュータ媒介言語
PCI DSS
FedRAMP
HIPAA / HITECH
エッセンシャル・エイト
シンガポールCCoP(CII向け)
サイバーセキュリティ法関連(APPI)

第3章 開発におけるコンプライアンスの導入

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

関連ブログ記事

すべて見る
すべて見る
2024年6月4日
-
コンプライアンス

SOC 2認証:私たちが学んだ5つのこと

監査中にSOC 2について学んだこと。ISO 27001とSOC 2の比較、タイプ2が理にかなっている理由、米国の顧客にとってSOC 2認証がいかに不可欠であるか。

2024年1月16日
-
コンプライアンス

NIS2:誰が影響を受けるのか?

NIS2は誰に適用されるのか?誰に影響するのか?必要不可欠で重要なセクターと企業規模の基準値は?AikidoアプリにはNIS2レポート機能があります。

2023年12月5日
-
コンプライアンス

ISO 27001認証:私たちが学んだ8つのこと

ISO 27001:2022準拠プロセスを開始する前に知っておきたかったこと。ISO27001認証取得を目指すSaaS企業へのヒントをご紹介します。

会社概要
製品価格について採用情報お問い合わせパートナー制度
リソース
資料公開APIドキュメント脆弱性データベースブログインテグレーション用語集プレスリリースカスタマーレビュー
産業別
ヘルステックメドテックフィンテックセキュリティテックリーガルテックHRテックエージェント向け企業向けPEおよびグループ会社向け政府・公共機関向けスマート・マニュファクチャリング&エンジニアリング
セキュリティ
トラストセンターセキュリティの概要クッキー設定の変更
リーガル
プライバシーポリシークッキーポリシー利用規約マスターサブスクリプション契約データ処理契約
使用例
コンプライアンスSAST & DASTASPM脆弱性管理SBOMの生成WordPressセキュリティコード保護マイクロソフトのためのAikidoAikido ためのAikido
比較する
全ベンダーとの比較vs Snyk対Wizvs Mendvs オルカ・セキュリティvs Veracodevs GitHubアドバンスドセキュリティvs GitLab Ultimatevs Checkmarxvs Semgrepvs SonarQube
リンクする
hello@aikido.dev
LinkedInX
サブスクライブ
すべての最新情報を入手
まだまだ。
👋🏻 ご登録ありがとうございます!
チーム Aikido
まだまだ。
© 2025 Aikido Security BV | BE0792914919
🇪🇺 登録住所:Coupure Rechts 88, 9000, Ghent, Belgium
🇪🇺 事務所所在地:Gebroeders van Eyckstraat 2, 9000, Ghent, Belgium
🇺🇸 事務所住所:95 Third St, 2nd Fl, San Francisco, CA 94103, US
SOC 2
コンプライアンス
ISO 27001
コンプライアンス