2026년 ISO 15118 인증 수명주기 관리: TLS 긴급성부터 CRA 준수까지

요약 (행정 조치 요약)

• TLS 전환은 명확한 경계이며, 권장 사항이 아닙니다. 에서 2026년 2월 24일디지서트는 수락을 중지하세요 유효 기간이 있는 공개 TLS 인증서 요청 199일 이상그리고 그 날짜부터 발급된 증명서에는 다음과 같은 내용이 포함됩니다. 최대 유효기간 199일이는 많은 통신 사업자에게 실질적인 전환점이며, 갱신 속도가 즉시 증가합니다.
• 200일→100일→47일 로드맵은 이미 확정되었습니다. CA/브라우저 포럼의 기본 요구사항은 단계적 감소를 설정합니다. 2026년 3월 15일부터 200일, 2027년 3월 15일부터 100일, 그리고 2029년 3월 15일부터 47일.
• 캐나다 국세청(CRA)이 규정 준수 기한을 추가했습니다. CRA 보고 규정은 다음과 같은 사항을 요구합니다. 24시간 이내 조기 경보, 72시간 이내에 전체 내용 통지또한, 현재 활발히 악용되고 있는 취약점 및 심각한 사고에 대한 최종 보고 기간을 정의했습니다.
• 숨겨진 가장 큰 위험은 만료가 아닙니다. 시스템적 고장 모드는 다음과 같습니다. 신뢰 앵커 드리프트— EVSE, 로컬 컨트롤러 및 백엔드 유효성 검사 경로 전반에 걸쳐 루트/중간/교차 서명 변경 사항이 동기화되지 않습니다.
• 가동 시간 보장을 위한 첫 번째 투자: 시스템 주도 자동화(ACME + 재고 관리 + 단계적 출시) 에지 연속성 (로컬 유효성 검사/캐싱, 증거 로그 및 시간 동기화 관리).

서론: 2026년은 플러그 앤 차지(Plug & Charge)를 실제 운영 시스템으로 전환하는 해입니다.

2026년에는 플러그 앤 차지(P&C) 기능이 더 이상 "설정 후 잊어버리는" 기능이 아니라 필수적인 기능으로 자리 잡게 됩니다. 연속 운영 체제.
ISO 15118 신뢰 영역(PKI + TLS + 해지 + 업데이트)은 이제 수동 워크플로를 허용하지 않는 타임라인에 따라 관리됩니다.

ISO 15118의 책임 범위와 OCPP의 책임 범위를 구분하는 시스템 경계를 이해하려면, 먼저 관련 자료를 참조하십시오.
ISO 15118과 OCPP 구축의 현실 (2026년).

당장의 압박은 다음과 같습니다. TLS 수명주기 압축현실적으로 "3월까지 기다릴" 수는 없습니다.
디지서트(DigiCert)는 수락을 중지하세요 공개 TLS 요청이 초과되었습니다. 199일 시작 2026년 2월 24일,
그리고 그날부터 발급되는 증명서에는 다음과 같은 내용이 포함됩니다. 최대 유효기간 199일.
DigiCert는 또한 중요한 운영상의 세부 사항을 강조합니다. 즉, 허용되는 최대 유효 기간은 다음 요인에 의해 결정됩니다. 발행일주문 시점이 아닙니다.

동시에 EU 사이버 복원력법(CRA)은 두 번째 시계를 도입합니다. 보고 규칙은 다음과 같은 사항을 요구합니다.
24시간 조기 경보 그리고 72시간 사전 통지 디지털 요소를 포함하는 제품에 영향을 미치는, 활발하게 악용되는 취약점 및 심각한 사고에 대한 정보입니다.

이 가이드는 이러한 제약 조건 하에서 ISO 15118 인증서를 운영하기 위한 아키텍처 및 위험 관리 방안에 중점을 둡니다.

2024~2026년 주요 일정 및 필수 조치 (텍스트 간트 차트)

운영 참고 사항: 2026년 2월 24일은 주요 신용평가기관의 발행 행태가 바뀌는 시점이므로 실질적인 전환점이 되는 경우가 많습니다.

정책 참고 사항: 단계별 수명 단축은 기준 요구사항(200/100/47일)에 명시되어 있습니다.

수명주기 개요: 프로비저닝 → 운영 → 갱신 → 해지

제품 수명 주기 맵 (반드시 운영할 수 있어야 하는 사항)

1. OEM 프로비저닝: 키가 생성/주입되었으며, 신뢰 루트가 설정되었습니다(HSM/보안 요소).
2. 계약 등록: 사용자 계약에 연결된 계약 인증서(생태계에 따라 다름).
3. 전기차 충전기 시운전: 트러스트 스토어 기준선, 정책 및 시간 동기화 기준선이 설정되었습니다.
4. 운영 검증: TLS 핸드셰이크, 체인 구축, 해지 확인, 정책 시행.
5. 갱신/재발급: 자동화 + 단계적 배포 + 롤백.
6. 취소/사고 대응: 침해/잘못 발급/악용 → 취소/교체/복구.
7. 복구 및 화해: 감사 가능성과 청구 정확성을 유지하면서 서비스를 복구합니다.

과소평가된 실패 지점: 신뢰 앵커 드리프트

다수의 OEM 환경에서 발생하는 대부분의 "원인 불명의 P&C 오류"는 단순히 만료된 인증서 하나가 아니라, 여러 가지 원인이 복합적으로 작용하는 것입니다.
경로 유효성 검사 실패 신뢰 앵커 드리프트로 인해 발생함:

• 새로운 뿌리/중간체가 나타난다(다중 뿌리 현실).
• 교차 서명 변화는 실행 가능한 연결 고리를 바꿉니다.
• 백엔드 트러스트 스토어는 EVSE/로컬 컨트롤러보다 더 빠르게 업데이트됩니다.
• 취소 관련 자료는 가장자리에서 효력을 잃습니다.

신뢰 앵커 업데이트를 안전에 매우 중요한 변경 프로세스로 취급하십시오.

• 버전 관리되는 신뢰 저장소
• 카나리 출시
• 계획 되돌리기
• 발급자/일련번호/경로별 유효성 검사 실패에 대한 원격 측정 데이터
• "누가 언제 무엇을 업데이트하는지"에 대한 명확한 담당자

교차 표지판 설치 및 경로 구축 실패(2026년 현실): 다중 루트 ISO 15118 생태계에서,
플러그 앤 차지 기능이 실패하는 이유는 인증서가 유효하지 않아서가 아니라, 전기차 충전기가 유효한 연결을 구축할 수 없기 때문인 경우가 많습니다.
인증서 경로 교차 서명 변경 후 (새로운 중간체, 브리지 CA, 재발행된 체인).
OEM 및 PKI 도메인이 더 많이 참여할수록 경로 복잡성이 증가합니다. 엣지 트러스트 스토어(EVSE/로컬 컨트롤러)를 사용하는 경우
백엔드 업데이트가 지연되면 백엔드 인증서가 개별적으로는 "유효"해 보이더라도 TLS 핸드셰이크가 실패할 수 있습니다.

그림 1 (권장 시각 자료): 다중 루트 ISO 15118의 경로 유효성 검사

(V2G 루트/OEM 루트/계약 루트, 중간 경로 및 교차 서명 브리지를 표시합니다.)
(신뢰 저장소가 동기화되어 업데이트되지 않을 경우, 새로 교차 서명된 중간체가 EVSE에서 경로 구축을 중단시키는 지점을 강조 표시하십시오.)

핵심 메시지: 대부분의 P&C 장애는 "PKI" 때문이라고 하지만, 실제로는 다른 원인으로 발생합니다. 경로 유효성 검사 실패 서명 오류 및 동기화되지 않은 신뢰 저장소로 인해 발생합니다.

ACME 및 자동화: 199/200일 수명 주기 내 인간 주도 방식 vs 시스템 주도 방식

수동 갱신이 필연적으로 장애를 유발하는 이유는 무엇일까요?

짧은 사용 기간으로 인해 갱신이 지속적으로 이루어집니다. DigiCert는 이러한 이유로 다음과 같은 조치를 취했습니다. 2026년 2월 24일부터 199일
이를 통해 많은 운송업체에서 즉시 운영이 가능해집니다. 그리고 더 넓은 산업 차원의 일정은 이미 정해져 있습니다.
200일 (2026년 3월 15일부터) 100일, 그 다음에 47일.

모든 차량 관리 시스템에서 갱신 이벤트는 다음과 같이 규모가 커집니다.

연간 갱신 횟수 ≈ N × (365 / L)

어디 N TLS 엔드포인트의 수입니다. 엘 인증서 유효기간(일)입니다.
처럼 엘 감소하면, 사람이 주도하는 갱신은 가동 시간 목표와 수학적으로 양립할 수 없게 됩니다.

시나리오 (이사회 차원의 규모 조정)

CPO 운영의 경우 5,000개의 엔드포인트199일이라는 수명은 다음을 의미합니다.

갱신 이벤트/연간 ≈ 5000 × (365 / 199) ≈ 9,171

이 정도 규모라면, 심지어 1% 인적 오류율 대략 다음과 같이 번역됩니다.
연간 92건의 인증서 관련 시스템 장애 발생—혼잡 시간대의 영향을 고려하기 전에,
SLA 위반에 따른 벌금 또는 허브 전체에 걸친 연쇄 장애.

충전 네트워크에서 ACME가 자동화해야 할 사항

ACME(자동화된 인증서 관리 환경)는 갱신을 정책 기반 운영으로 전환합니다.

• EVSE ↔ 백엔드 TLS
• 로컬 컨트롤러/엣지 프록시 TLS
• 사이트 게이트웨이 및 허브 컨트롤러

시스템 주도 워크플로우(아키텍처 패턴)

1. 목록 모든 엔드포인트(발급사, 일련번호, 체인, 만료일, 마지막 회전일).
2. 정책 갱신 전 (만료 임박이 아닌, 정해진 기준에 따라 갱신).
3. 하드웨어 지원 키 가능한 한 개인 키는 내보내지 마십시오.
4. 단계적 출시 상태 확인(핸드셰이크 + 인증 + 세션 시작)을 포함합니다.
5. 자동 롤백 고장률이 높아진 것에 대해.
6. 증거 기록 모든 발행/배포 건에 대해 (규정 준수 수준의 추적성).

인간 주도형 vs 시스템 주도형

• 사람 주도형: 티켓 관리, 스프레드시트, 늦은 갱신, 모호한 담당자 지정, 위험한 긴급 변경.
• 시스템 주도형: 확정적 정책, 자동 발급, 통제된 배포, 지속적인 원격 측정, 감사 가능한 증거.

취소 확인: "정책 및 규정의 킬러" (CRL 대 OCSP, 취약한 네트워크 및 방어 가능한 정책)

차고 및 창고에서 OCSP/CRL이 실패하는 이유는 무엇일까요?

• LTE/5G 연결이 약하거나 간헐적입니다.
• 출입 제한(방화벽/캡티브 포털)
• 지연 시간에 민감한 검증 단계
• 외부 종속성(OCSP 응답자, CRL 배포 지점)

결과: EVSE는 세션을 시작할 수는 있지만 완료하지 못합니다. 취소 유효성 검사 믿을 수 있게.

CRL과 OCSP: 실질적인 장단점 비교

• CRL: 다운로드 용량은 더 크지만 캐시 가능하고 예약된 시간에 새로 고침할 수 있습니다(엣지 네트워크 연속성에 유리함).
• OCSP: 요청당 처리량은 적지만, 가장 취약한 에지에서 실시간 연결이 필요한 경우가 많습니다.

2026년에는 올바른 자세가 계층적으로 형성됩니다.

• 복원력을 위한 예약된 CRL 캐싱
• 연결이 안정적인 OCSP
• 열악한 환경에 대한 명확한 정책

'소프트 페일'을 옹호하기가 점점 더 어려워지는 이유

과거에는 "소프트 페일"(취소 확인 시간 초과 시 세션 허용)을 통해 가용성을 유지했습니다.
2026년에는 소프트 페일을 정당화하기가 더욱 어려워집니다. 그 이유는 다음과 같습니다.

• 수명이 짧아집니다(오래된 가정에 대한 허용치가 낮아짐).
• CRA의 보고 기한은 사건 처리 및 증거 추적을 강화합니다.

방어 가능한 설계를 위해서는 명확하고 문서화된 정책이 필요합니다.

• 심각한 오류 공공/고위험 환경용
• 증거가 있는 은혜 폐쇄형 함대(제한된 기간 + 보완 제어)의 경우
• 증거 기록 모든 잘못된 결정에 대해

아키텍처적 완화책 (제품 약속이 아닌 패턴)

패턴 1: 엣지 사전 검증 + 캐싱

• 정의된 최신성 기간을 가진 캐시 CRL
• 캐시 중간체 및 검증된 체인
• 연결 상태가 양호한 기간 동안 미리 가져오기

패턴 2: OCSP 스테이플링(가능한 경우)

OCSP 스테이플링은 가장 취약한 에지에서 해지 증명 전달을 다른 곳으로 이동시켜 세션 설정 중 CA 인프라에 대한 실시간 의존도를 줄입니다.

구현 참고 사항(임베디드 리얼리티): EVSE 환경에서 스테이플링 관련 확장 지원 여부를 확인하십시오.
내장 TLS 스택 및 빌드 구성(예: mbedTLS, wolfSSL)에서 레거시 하드웨어 전반에 걸쳐 동작을 검증하십시오.
기능 완성도와 메모리/RTOS 제약 조건이 다양하기 때문입니다.

패턴 3: 다중 루트 트러스트 거버넌스

• 다수의 OEM 앵커를 위한 통합 트러스트 스토어 업데이트 채널
• 카나리 업데이트 및 경로 구축 오류 급증 시 롤백

패턴 4: 시간 동기화 관리(협상 불가)

• NTP 정책(또는 적절한 경우 PTP 정책)
• 드리프트 모니터링 및 경고 임계값
• 시계를 신뢰할 수 없을 때 정의된 동작

오프라인 연속성: 엣지-클라우드 연결 끊김 중에도 Plug & Charge 기능을 계속 사용할 수 있도록 유지

오프라인 연속성이란 무엇이며, 무엇이 아닌가?

오프라인 연속성은 "PKI 우회"가 아닙니다. 이는 다음과 같은 사항을 보존하는 제어된 데이터 손실입니다.

• 키 및 신뢰 저장소의 무결성
• 청구 및 사고 대응에 대한 감사 가능성
• 로컬에서 검증할 수 있는 항목에 대한 명확한 제한 사항(및 검증 기간)

로컬 컨트롤러/엣지 프록시는 가용성 기본 요소입니다.

• 로컬 신뢰 캐시(앵커/중간 저장소/CRL)를 유지 관리합니다.
• 제한적인 현지 승인 정책을 시행하십시오
• 추후 조정 작업을 위한 버퍼 미터링/로그
• EVSE의 로컬 엔드포인트 역할을 하여 WAN 영향 범위를 줄이십시오.

그림 2(권장 시각 자료): 네트워크 상태가 취약한 사이트에서 신뢰 캐시 역할을 하는 에지 프록시

(현장 에지 프록시/로컬 컨트롤러에 연결된 EVSE를 보여줍니다. 프록시는 캐시된 신뢰 앵커/중간 장치를 유지합니다.)
정기적인 CRL 갱신, 시간 동기화 모니터링 및 증거 로그를 제공하며, 업링크가 불안정할 경우 클라우드 CSMS/PKI로 이벤트를 버퍼링합니다.

핵심 메시지: 엣지 프록시는 외부 OCSP/CRL 엔드포인트에 대한 실시간 의존성을 줄이고 PKI를 우회하지 않고도 제어된 오프라인 연속성을 가능하게 합니다.

CRA 및 VMP: 2026년 9월 보고 기한에서 감사 가능한 운영 모델로

CRA 보고 규칙: 24시간/72시간 기준 설계

CRA 보고 규정에 따라 제조업체는 현재 악용되고 있는 취약점과 심각한 영향을 미치는 사고를 보고해야 합니다.
디지털 요소가 포함된 제품의 보안에 관하여:

• 24시간 이내 조기 경보 자각하게 되는 것
• 72시간 이내에 전체 알림 제공
• 최종 보고서 (사건 유형에 따라) 정해진 기간 내에

대규모 충전 서비스 중단은 대량 등록 취소 또는 신뢰 기반 손상으로 인해 발생할 수 있습니다. 자격이 될 수 있습니다
영향 및 악용 증거에 따라 심각한 사건으로 간주될 수 있습니다.

취약점 관리 프로세스(VMP): 최소 필수 기능

1. 함대 진실: 자산 + 버전 목록(EVSE 펌웨어, 컨트롤러 이미지, 트러스트 스토어 버전).
2. SBOM 통합(동적): SBOM을 배포 가능한 아티팩트에 매핑하고, 취약점 정보와 지속적으로 상관관계를 분석합니다.
3. VEX 기반 노출 관리: VEX 문장을 유지하여 "존재하지만 악용할 수 없는" 상태와 "배포 환경에서 악용 가능한" 상태를 구분함으로써 T+24시간 내에 신뢰할 수 있는 범위 설정을 가능하게 합니다.
4. 24시간 시계 시대에 VEX가 중요한 이유: SBOM은 무엇이 존재하는지 알려주고, VEX는 무엇이 존재하지 않는지 판단하는 데 도움을 줍니다. 악용 가능한이를 통해 오경보를 줄이고 운영팀이 활용 불가능한 노이즈를 쫓는 것을 방지합니다.
5. 접수 및 분류: 공급업체 권고사항, CVE, 내부 조사 결과 등을 종합하여 악용 가능성 및 노출도를 우선시합니다.
6. T+24시간 범위 설정 워크플로: SBOM + VEX + 재고 상관관계 분석을 통해 감염된 개체군을 식별하고, 초기 격리 결정을 내리고, 증거를 수집합니다.
7. T+72시간 알림 워크플로: 확정된 범위, 완화 조치, 배포/철수 계획, 커뮤니케이션 기록.
8. 최종 보고서 작성 워크플로: 검증 증거 + 근본 원인 + 시정 조치 시행 후 예방 개선 사항.
9. 패치 주기 엔지니어링: 단계별 배포, 롤백 계획, 서명된 산출물, 검증 게이트.
10. 신뢰 사슬 시행: 보안 부팅 + 보안 펌웨어 업데이트; 서명 키는 HSM/보안 요소에 보호됩니다.
11. 증거 중심의 로깅: 인증서 이벤트, 신뢰 저장소 변경 사항, 해지 실패, 시간 동기화 상태.

신뢰도 하락 심각 시나리오: 루트 키 또는 발급 키가 손상되어 해지가 발생하는 경우,
이를 즉각적인 조치와 함대 전체 신뢰 저장소 조치가 필요한 최고 심각도 신뢰 사고로 처리하십시오.
또한, 영향 및 착취 증거에 따라 CRA(캐나다 재투자법)에 부합하는 보고 준비 상태를 갖춥니다.

CRA 사고 대응 카운트다운 체크리스트(운영 템플릿)

T+0 (탐지/인식)

• 증거 동결: 로그, 인증서 이벤트, 트러스트 스토어 버전, 시간 동기화 상태
• 영향을 받는 부분을 식별하십시오: EVSE 펌웨어, 로컬 컨트롤러, 백엔드 TLS 엔드포인트
• PKI 제공업체/백엔드 보안 담당자에게 문의하십시오.

T+24시간 (조기 경보 준비 태세)

• 핵심 목표: 사용 SBOM + VEX + 함대 재고 영향을 받는 인구를 파악하고 증거에 기반한 조기 경보 시스템을 구축한다.
• 격리 방안 결정: 권한 취소/순환, 트러스트 스토어 롤백, 사이트 격리
• 조기 경보 패키지 초안: 범위, 진행 중인 완화 조치, 잠정적 대응 방안

T+72시간 (완전한 알림 준비 완료)

• 지역/현장별 피해 인구를 확인하고, 복구 계획 및 실행 방법을 제시하십시오.
• 고객/운영자 통신 내용 및 문제 해결 기록을 작성하십시오.

최종 보고서 제출 기간

• CRA 요건에 맞춰 최종 보고서를 제출하십시오(제출 시기는 사건 유형에 따라 다릅니다).
• 수정 후 검증 증거 및 교훈

비용 및 위험 정량화 (운영 중인 시스템에 바로 적용할 수 있는 템플릿)

수동 갱신 인건비 모델

허락하다:

• N = TLS 엔드포인트 수 (EVSE + 컨트롤러 + 게이트웨이 + 관리형 백엔드 노드)
• 엘 = 인증서 유효기간(일)
• 티 = 갱신당 소요되는 인력 시간(시간)
• 기음 = 모든 비용을 포함한 인건비(미국 달러/시간)

노동비용 ≈ N × (365 / L) × t × c

장애 위험 모델(만료 또는 배포 실패)

허락하다:

• 피미스 = 주기당 갱신 누락/실패 확률
• H_다운 = 사고당 예상 가동 중지 시간(시간)
• C_시간 시간당 사업 영향(매출 손실, 벌금, SLA 크레딧)

비용_정전 ≈ P_miss × H_down × C_hour

온라인 계정 취소 확인 실패 시(OCSP/CRL 시간 초과) 결정 가이드

1. 공공 시설인가요, 아니면 폐쇄된 차량기지/창고인가요?
   • 공개 → 선호 심각한 오류 (또는 증거와 보완적인 통제를 통해 엄격하게 통제된 은혜만 허용됨)
   • 함대/창고 → 증거가 있는 은혜 제한된 기간 내에는 허용될 수 있습니다.
2. 네트워크 안정성은 예측 가능한가요?
   • 예 → 온라인 OCSP/CRL + 모니터링
   • 아니요 → 엣지 사전 검증 + 캐싱 (CRL 새로 고침 시간, 캐시된 체인)
3. 세션 시간 동안 온라인 의존도를 줄일 수 있을까요?
   • 가능한 경우 → 채택 OCSP 스테이플링 패턴 (증거를 가장자리 쪽으로 더 밀어주세요)
4. 증거 기록 및 시간 동기화 관리 기능을 갖추고 계신가요?
   • 그렇지 않다면 → 먼저 이것들을 해결하세요. 이것들이 없으면 저하된 모드 정책을 옹호하기 어렵습니다.

실질적인 책임 매트릭스 (정전을 방지하는 경계)

어휘

• PKI: 공개 키 인프라(발급, 유효성 검사, 신뢰 앵커, 폐지)
• 절정: 자동화된 인증서 관리 환경(자동 발급/갱신)
• OCSP/CRL: 온라인 인증서 상태 프로토콜 / 인증서 폐지 목록
• OCSP 스테이플링: 서버는 실시간 OCSP 의존성을 줄이기 위해 해지 증명을 제공합니다.
• 신뢰의 기준: 검증자가 신뢰하는 루트/중간 인증서
• SBOM: 소프트웨어 구성 요소 목록(취약점 범위 설정을 위한 구성 요소 목록)
• VEX: 취약점 악용 가능성 교환(악용 가능성 상태 설명)
• TLS 1.3: 최신 TLS 프로파일; 핸드셰이크 및 인증서 유효성 검사는 여전히 지연 시간에 민감합니다.
• VMP: 취약점 관리 프로세스(접수, 분류, 패치, 보고, 증거 수집)

미래예측 위험: 암호화폐 민첩성 및 PQC 준비 상태

2026년에는 짧은 TLS 수명과 CRA 보고가 주를 이루겠지만, 충전 인프라는 다음 사항들을 평가하기 시작해야 합니다.
암호화 민첩성차량 및 충전기와 같이 수명이 긴 자산의 경우, 아키텍처는 하드웨어 종속성을 방지하기 위해 다음과 같은 사항을 보장해야 합니다.
HSM/보안 요소 및 내장 스택은 하드웨어 교체 없이도 향후 알고리즘 및 인증서 프로필 업데이트를 지원할 수 있습니다.

자주 묻는 질문

Plug & Charge는 오프라인에서도 작동하나요?

부분적으로는 의도적으로 그렇게 설계되었습니다. 오프라인 P&C는 로컬 신뢰 캐싱(가능한 경우 앵커/중간체/CRL)을 사용하여 제어된 성능 저하를 구현합니다.
명시적인 유예 정책과 조정을 위한 버퍼링된 감사 로그를 사용해야 합니다. PKI를 우회해서는 안 되며, 실시간 클라우드 의존성을 줄여야 합니다.
무결성과 감사 가능성을 유지하면서.

유효기간이 199일/200일 미만인 인증서는 얼마나 자주 갱신해야 하나요?

엔드포인트별로 연간 여러 번의 갱신 주기를 계획하십시오. 많은 통신 사업자에게 있어 운영 전환은 다음과 같이 시작됩니다.
2026년 2월 24일 DigiCert는 최대값이 있는 공개 TLS 인증서를 발급하기 때문입니다. 199일 해당 날짜부터 유효합니다.
보다 광범위한 생태계 차원에서, 기본 요구사항은 단계적 감축을 정의합니다. 200/100/47일.

캐나다 국세청(CRA) 보고 의무 발생 원인은 무엇인가요?

CRA 보고 규정은 다음과 같은 사항을 요구합니다. 24시간 조기 경보 그리고 72시간 사전 통지 활발하게 악용되는 취약점 및 심각한 사고에 대해,
최종 보고 기간을 포함합니다. 대규모 P&C 신뢰 파괴(예: 악의적인 취소 또는 유효성 검사 침해)는 경우에 따라 해당될 수 있습니다.
영향 및 악용 증거에 관하여; CRA 준비가 완료된 VMP는 다음을 지원해야 합니다. SBOM + VEX + 함대 재고 첫 24시간 이내에 내시경 검사를 실시합니다.