製品
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章

PCI DSS

6分で読めます150

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

要約

クレジットカードデータを扱う場合、PCI DSSは必須です。これは、カード会員データ (CHD) および機密認証データ (SAD) を保護する方法(暗号化、ファイアウォール、アクセス制御、ロギング、スキャンなど)を網羅しています。

これを怠ると、罰金、侵害、訴訟、そして決済処理業者からのサービス停止のリスクを負います。コンプライアンスは選択肢ではなく、生き残りのために不可欠です。

PCI DSSスコアカード概要:

  • 開発者の労力: 中程度から高い(セキュアコーディング、セキュアな構成、カード会員データの慎重な取り扱い、アクセス制御の順守、脆弱性スキャン/ロギングのサポートが必要)。
  • ツール費用: 中程度から高い(ファイアウォール、脆弱性スキャナー(ASVスキャン)、ファイル整合性監視、ロギング/SIEM、暗号化ツール。トークン化/P2PEソリューションも必要となる可能性あり)。
  • 市場への影響: 非常に重要(決済カードデータを取り扱うすべての事業体に義務付けられています。非遵守はカード決済処理不能につながる可能性があります)。
  • 柔軟性: 低~中程度(中核となる要件は規定されていますが、具体的な実装方法は異なる場合があります。v4.0では「customized approach」により柔軟性が向上しています)。
  • 監査の厳格度:高(自己評価質問書(SAQ)または認定セキュリティ評価者(QSA)による正式なコンプライアンス報告書(ROC)による年次検証、および四半期ごとの脆弱性スキャンが必要です)。

PCI DSSとは何ですか?

Payment Card Industry Data Security Standard (PCI DSS)は、データ処理と保存に関する管理を強化することでクレジットカード詐欺を防止するために設計された、グローバルな情報セキュリティ標準です。これは、規模や場所に関わらず、カード会員データ(CHD)または機密認証データ(SAD)を受け入れ、処理し、保存し、または送信するあらゆる組織に適用されます。

CHDには、プライマリアカウント番号(PAN)、カード所有者名、有効期限、サービスコードが含まれます。SADには、完全なトラックデータ、カード認証コード(CVV2、CVC2など)、およびPINが含まれます。SADは認証後に決して保存してはなりません。

PCI DSSは、主要な決済カードブランド(Visa、Mastercard、American Express、Discover、JCB)によって策定されました。これらのブランドは、標準を管理するためにPCI Security Standards Council(PCI SSC)を設立しました。コンプライアンスは、PCI SSCが直接ではなく、個々のカードブランドとアクワイアリング銀行によって強制されます。

この標準は、6つの目標を中心に構成されており、これらは12の中核要件に具体化されます(これらは新しいPCI DSS v4.0においても概念的には一貫しています)。

  1. 安全なネットワークとシステムを構築・維持する:
    • 要件1:ネットワークセキュリティ制御(ファイアウォール)を導入および維持する。
    • 要件2:すべてのシステムコンポーネントに安全な構成を適用する。
  2. アカウントデータの保護:
    • 要件3:保存されたアカウントデータを保護する(例:PANを暗号化する)。
    • 要件4:オープンな公共ネットワークでの送信中に、強力な暗号化によってカード会員データを保護する。
  3. 脆弱性管理プログラムを維持します。
    • 要件5:すべてのシステムとネットワークを悪意のあるソフトウェアから保護する。
    • 要件6:安全なシステムとソフトウェアを開発および維持する(パッチ適用、セキュアコーディング)。
  4. 強固なアクセス制御策を導入します。
    • 要件7:業務上の必要性に基づいて、システムコンポーネントおよびカード会員データへのアクセスを制限する。
    • 要件8:ユーザーを識別し、システムコンポーネントへのアクセスを認証する。
    • 要件9:カード会員データへの物理的なアクセスを制限します。
  5. ネットワークを定期的に監視およびテストする:
    • 要件10:システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視します。
    • 要件11: システムとネットワークのセキュリティを定期的にテストします(脆弱性スキャン、ペネトレーションテスト)。
  6. 情報セキュリティポリシーの維持:
    • 要件12:組織のポリシーとプログラムにより情報セキュリティをサポートします。

コンプライアンス検証は、年間処理されるトランザクション量(マーチャントレベル1-4、サービスプロバイダーレベル1-2)に基づいて異なり、年次の自己評価質問書(SAQ)から、認定セキュリティ評価機関(QSA)による正式なオンサイト監査を経てコンプライアンス報告書(ROC)が発行されるものまで多岐にわたります。通常、認定スキャンベンダー(ASV)による四半期ごとの外部脆弱性スキャンが義務付けられています。PCI DSS v4.0が現在のバージョンであり、要件は2025年3月31日までに義務化されます。

なぜそれが重要なのか

支払いカードデータを扱うあらゆるビジネスにとって、PCI DSSコンプライアンスは絶対に不可欠です。

  • カード決済受け入れの要件: 主要なカードブランドが、アクワイアリング銀行との契約を通じて義務付けています。コンプライアンス違反は、カード決済を受け入れられなくなる原因となります。
  • データ侵害の防止: PCI DSSの制御を実装することで、コストのかかるカード会員データ侵害のリスクを大幅に軽減します。
  • Avoids Severe Penalties: 不遵守は、侵害が発生しなくても、アクワイアリング銀行/カードブランドから多額の月額罰金(月額5,000ドルから100,000ドル以上)を科される可能性があります。
  • 侵害の影響を軽減: 万一侵害が発生した場合でも、PCI DSSに準拠していることは適切な注意義務を果たしていることを示し、罰金、法的責任、および補償費用(カード再発行手数料など)を潜在的に削減できます。
  • 顧客の信頼を構築する: コンプライアンスは、支払いデータのセキュリティを真剣に扱っていることを顧客に示し、信頼とロイヤルティを育みます。
  • ブランドの評判を保護: カードデータ侵害は企業の評判に深刻な損害を与えます。PCI DSSはそれを防ぐのに役立ちます。
  • セキュリティベースラインの提供: 支払いデータだけでなく、組織全体のセキュリティ体制に利益をもたらす、強固なベースラインセキュリティフレームワークを提供します。

PCI DSSを無視することは、支払いカードを受け入れたい企業にとって選択肢ではありません。

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

PCI DSSの実装には、技術的制御と文書化されたポリシー/手順を通じて、12の主要要件すべてに対処することが含まれます。開発および運用に影響を与える主要な領域は次のとおりです。

  1. ネットワークの保護 (要件1および2):
    • カード会員データ環境(CDE)を他のネットワークから分離するために、ファイアウォールを導入し、維持します。
    • 安全な設定を使用します:ベンダーのデフォルトを変更し、不要なサービス/ポートを無効にし、システムを強化します。証拠:ファイアウォールルールセット、設定標準、ネットワーク図。
  2. カード会員データの保護 (要件3および4):
    • ストレージの最小化: カード会員データは、絶対に必要でない限り保存しないでください。承認後にSADを保存することは決してありません。
    • PANのマスク: 表示時にプライマリアカウント番号(PAN)をマスクします(最初の6桁と最後の4桁のみ表示)。
    • PANの暗号化: 強力な暗号化(例:AES-256)と堅牢な鍵管理を使用して、保存されたPANを読み取り不能にします。
    • 伝送の暗号化: オープン/パブリックネットワーク経由での伝送中にCHDを暗号化します(強力なTLSバージョン、セキュアなプロトコルを使用)。証拠: データ保持ポリシー、データフロー図、暗号化設定、鍵管理手順。
  3. 脆弱性管理 (要件5および6):
    • アンチマルウェア: マルウェアが一般的に影響を与えるシステムにアンチマルウェアソリューションを展開し、定期的に更新します。
    • パッチ適用:セキュリティパッチを迅速に(重要なパッチについては定められた期間内に)特定し適用するプロセスを実装します。
    • Secure Coding: セキュアコーディングガイドライン(例:OWASP)に基づいてソフトウェアアプリケーション(内部または特注)を開発し、開発者をトレーニングし、一般的なコーディング脆弱性(インジェクション、XSSなど)に対処します。証拠:パッチ管理記録、セキュアコーディングポリシー、開発者トレーニング記録、SAST/DAST結果。
  4. アクセス制御 (要件7、8、9):
    • 最小権限の原則/知る必要性: 職務と最小限必要な権限に基づいて、CHDおよびシステムコンポーネントへのアクセスを制限します。
    • ユニークIDと認証: アクセスにはユニークIDを割り当て、強力な認証(複雑なパスワード/パスフレーズ、MFA - 特にCDEアクセス用)を実装してください。
    • 物理的セキュリティ: CHDを保存/処理するシステムへの物理的なアクセスを保護します。証拠: アクセス制御ポリシー、RBAC設定、MFA設定、パスワードポリシー、物理アクセスログ。
  5. 監視とテスト(要件10および11):
    • ロギング: すべてのシステムコンポーネントに対して詳細な監査ロギングを実装します。ネットワークリソースおよびCHDへのアクセスを追跡します。ログを改ざんから保護します。時刻同期(NTP)を使用します。
    • ログレビュー: 不審なアクティビティがないか、定期的にログをレビューします。
    • 脆弱性スキャン:四半期ごとの外部ASVスキャンと内部脆弱性スキャンを実行します。脆弱性に対処します。
    • ペネトレーションテスト: 年次で内部/外部ペネトレーションテストを実施します(および大幅な変更後にも)。
    • 侵入検知/防御:IDS/IPSを実装します。
    • 変更検出: 重要なファイルにはファイル整合性監視(FIM)を使用します。証拠:ログレビュー手順、SIEM構成、ASVスキャンレポート、ペンテストレポート、FIMログ。
  6. 情報セキュリティポリシー(要件12):
    • 包括的な情報セキュリティポリシーを維持し、毎年レビューし、関連する担当者に配布します。
    • セキュリティ責任を定義し、意識向上トレーニングを実施します。
    • インシデント対応計画を導入し、テストします。証拠: 情報セキュリティポリシー文書、トレーニング記録、インシデント対応計画およびテスト結果。

PCI DSS v4.0では、より強力なパスワード/MFA要件、管理策の適用範囲の拡大、フィッシング対策および支払いページでのスクリプトセキュリティに関する新しい要件などの更新が導入され、従来の「定義されたアプローチ」に加えて、特定の条件下で要件を満たすための「カスタマイズされたアプローチ」が許可されています。

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

PCI DSSコンプライアンスの達成と維持はしばしば困難です。これらの一般的なエラーを避けてください:

  1. 不正確なスコープ設定: CHDを保存、処理、または送信する、あるいはCDEのセキュリティに影響を与える可能性のあるすべてのシステム、ネットワーク、およびアプリケーションを正確に識別できないこと。これは最も重大な誤りです。
  2. 機密認証データ(SAD)の保存: 認証後にCVV2、フルトラックデータ、またはPINデータを違法に保存すること。
  3. 不適切なデータ保護: 暗号化されていないPANの保存、脆弱な暗号化・鍵管理の使用、または安全でないチャネルでのCHDの送信。
  4. 脆弱なアクセス制御: 共有/デフォルトの認証情報の使用、CDEアクセスにおけるMFAの不足、最小特権の不履行、アクセスの迅速な失効の失敗。
  5. 不十分なロギングと監視:関連するイベントをログに記録しない、ログを定期的にレビューしない、またはログを改ざんから保護しないこと。
  6. Ignoring Vulnerability Management: 四半期ごとのASVスキャンをスキップすること、内部スキャンに失敗すること、重要な脆弱性を迅速にパッチ適用しないこと。
  7. セキュアコーディングプラクティスの不備: CHDを露出させる一般的な脆弱性(SQLi、XSS)を持つアプリケーションを開発しています。
  8. ポリシーと手順の軽視: 文書化されたポリシー、手順、またはインシデント対応計画がないこと、あるいは従業員のトレーニングを怠ること。
  9. ベンダーのコンプライアンス: 第三者サービスプロバイダーが準拠していると、検証なしに、または適切な契約合意なしに仮定すること。
  10. コンプライアンスを年次と見なすこと: PCI DSSを継続的なセキュリティプロセスではなく、単なる年次監査/SAQと見なすこと。

監査人/QSAが尋ねる可能性のあること (開発者向け)

PCI DSSの監査を行う認定セキュリティ評価機関 (QSA) は、要件6(セキュアなシステムとソフトウェア)に関連する開発プラクティスを調査します。

  • (要件6.2) 「セキュアソフトウェア開発ライフサイクル(SSDLC)プロセスについて説明してください。」
  • (要件6.2.1) 「カスタムおよび特注ソフトウェアは、業界標準および/またはPCI DSS(例:OWASPのようなセキュアコーディングガイドライン)に基づいてどのように開発されていますか?」
  • (要件6.2.2) 「開発者はセキュアコーディング技術についてどのようにトレーニングされていますか?」(トレーニング記録を提示してください)
  • (Req 6.2.3) 「リリース前に、セキュリティ脆弱性についてコード変更はどのようにレビューされますか?」(コードレビュープロセスを説明してください)
  • (Req 6.2.4) 「開発/テスト環境と本番環境の間で職務分掌をどのように確保していますか?」
  • (Req 6.3) 「特注およびカスタムソフトウェアをどのように識別し、インベントリを作成していますか?」
  • (Req 6.4 - v4.0) 「支払いページスクリプトの整合性を確保し、スクリプトを承認するためにどのように管理していますか?」(ウェブ開発者向け)
  • (要件6.5 - v3.2.1 / v4.0の各種) 「インジェクションの欠陥、バッファオーバーフロー、安全でない暗号化ストレージ、XSSなどの一般的なコーディング脆弱性に対して、どのように保護していますか?」(コード例、ツール使用状況 - SAST/DASTの提示が必要)
  • (要件3) 「アプリケーション内で機密データ(PAN)がストレージでどのように保護されているか(暗号化、ハッシュ化、切り捨て)を示してください。」
  • (要件4) 「機密データが送信中にどのように暗号化されているかを示してください。」
  • (Req 8) 「アプリケーションはパスワードの複雑さとMFA要件をどのように強制しますか?」

QSAは、文書化されたプロセス、開発者トレーニング、セキュアコーディング標準の順守、コードレビュー、セキュリティテスト結果(SAST/DAST)、およびアプリケーション内のセキュアな設定の証拠を必要とします。

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

開発者はPCI DSSコンプライアンスに大きく貢献できます:

  1. SADを絶対に保存しない: コードが承認後にCVV2、トラックデータ、またはPINをログに記録、保存、または保持しないようにしてください。
  2. CHD処理の最小化: 可能であれば、CHDをシステムから完全に分離するサードパーティの決済処理業者/ゲートウェイを使用します(スコープを削減)。処理する必要がある場合は、その流れと保存場所を最小限に抑えます。
  3. セキュアコーディングの基本: 入力検証と出力エンコーディングを通じて、OWASP Top 10の脆弱性、特にインジェクション(SQLi、コマンドインジェクション)およびクロスサイトスクリプティング(XSS)の防止に焦点を当てます。
  4. データベースクエリのパラメータ化:SQLインジェクションを防ぐため、常にプリペアドステートメントまたはパラメータ化されたクエリを使用してください。
  5. PANの暗号化/ハッシュ化/トークン化: PANを保存する場合は、適切な鍵管理を備えた強力な標準暗号化(AES-256)を使用するか、トークン化ソリューションを検討してください。独自の暗号化方式を開発しないでください。
  6. 強固なTLSを使用する: すべてのCHD(カード会員データ)送信において、最新かつセキュアなTLSバージョンと強力な暗号スイートを使用していることを確認します。
  7. 入力検証の実装: ユーザーまたは外部システムからのすべての入力を厳密に検証します。
  8. セキュリティヘッダーの適用: HTTPセキュリティヘッダー(Content-Security-Policyなど)を使用して、XSSやその他のクライアントサイド攻撃を軽減します。これはv4.0の要件6.4で特に重要です。

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

PCI DSSを無視することは、財政的に破綻を招き、評判を壊滅させる可能性があります。

  • 月額罰金: アクワイアリング銀行は、非準拠に対して高額な罰金を課します。これは通常、月額5,000ドルから100,000ドル以上に及び、準拠レベルと非準拠の期間に基づいて増加します。
  • 取引手数料の増加: 銀行は、コンプライアンスに準拠していない加盟店に対して取引手数料を増やす可能性があります。
  • カードブランドによる罰金: カードブランドは直接、追加の罰金を課すことができます。
  • カード処理の終了: 銀行は支払いカードを受け入れる能力を完全に撤回でき、事実上、カード支払いによる収益源を停止させます。
  • データ侵害費用:コンプライアンス違反が侵害につながった場合、費用は急増します。これには、フォレンジック調査、カード交換費用(1枚あたり3~5ドル以上)、被害者への信用監視、弁護士費用、規制当局による罰金(適用される場合はGDPRなど)、および潜在的な訴訟が含まれます。
  • 評判の損害: コンプライアンス違反またはカードデータ侵害の公表は、顧客の信頼とブランドイメージに深刻な損害を与えます。
  • 監視の強化: コンプライアンス違反や侵害の後、組織は銀行やカードブランドからより厳しい監視に直面します。

よくあるご質問

誰がPCI DSSに準拠する必要がありますか?

主要なカードブランド(Visa、Mastercard、American Express、Discover、JCB)のカード会員データを受け入れ、処理し、保存し、または送信するすべての組織。これには、加盟店、サービスプロバイダー(決済処理業者、ホスティングプロバイダーなど)、および金融機関が含まれます。

PCI DSS v3.2.1とv4.0の違いは何ですか?

PCI DSS v4.0は最新バージョンであり、v3.2.1(2024年3月31日に廃止されますが、新しいv4.0要件は2025年3月31日までベストプラクティスです)に代わるものです。v4.0の主な変更点には、パスワード/MFA要件の更新、セキュリティ管理策の適用範囲の拡大、フィッシングおよびEコマーススキミング攻撃を対象とした新しい要件、より明確なガイダンス、そして従来の「定義されたアプローチ」に加えて要件目標を達成するための代替手段としての「カスタマイズされたアプローチ」の導入が含まれます。

加盟店レベル/サービスプロバイダーレベルとは何ですか?

これらは、処理するカード取引の年間量に基づいて組織を分類します。レベル1(最高量)は最も厳格な検証要件(QSAによる年次ROC、四半期ごとのASVスキャン)を持ちます。レベル2、3、4は徐々に量が少なくなり、通常、年次SAQと四半期ごとのASVスキャンを通じて検証されます。

QSAとASVとは何ですか?

QSA(認定セキュリティ評価機関)は、PCI SSCによって認定された個人であり、レベル1の加盟店/サービスプロバイダー向けにオンサイトのPCI DSS評価を実施し、準拠レポート(ROC)を作成します。ASV(承認済みスキャンベンダー)は、PCI SSCによって認定された組織であり、義務付けられている四半期ごとの外部ネットワーク脆弱性スキャンを実施します。

カード会員データ環境 (CDE)とは何ですか?

CDEは、カード会員データまたは機密認証データを保存、処理、または送信する人、プロセス、およびテクノロジーで構成されます。CDEのスコープを正確に定義することは、要件が主にこの環境内で適用されるため、PCI DSSコンプライアンスにおける重要な最初のステップです。ネットワークセグメンテーションは、CDEのスコープを削減するために使用できます。

CVV2コードを保存できますか?

いいえ。3桁または4桁のカード確認コード(CVV2、CVC2、CID、CAV2)、完全な磁気ストライプデータ、およびPINを含む機密認証データ(SAD)は、取引承認が完了した後、決して保存してはなりません。SADの保存は、重大なコンプライアンス違反です。

PCI DSSコンプライアンスは法的に義務付けられていますか?

PCI DSSはカードブランドによって作成された業界標準ですが、コンプライアンスは通常、加盟店、アクワイアリング銀行、およびカードブランド間の契約を通じて契約上義務付けられています。準拠しない場合、これらの契約に違反し、銀行/ブランドによって課される罰則につながります。個人データが関与する場合、GDPRのような法的要件と重複する可能性もあります。

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

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

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

www.aikido.dev/learn/software-security-tools/pci-dss

目次

第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
導入