SOC(시스템 및 조직 통제) 2 규정 준수는 감사를 통과하기 위해 한 번 시행하는 단순한 절차가 아닙니다. 영구적인 절차 변경은 지루하고 시간이 많이 걸리지만 조직이 SOC 2 감사를 통과하기 위해서는 반드시 필요합니다. 이는 단순히 CPA에게 서류 추적을 제공하는 것 이상의 의미가 있습니다. 규정 준수를 영구적으로 유지하거나 규정 준수 표준을 위반할 위험을 감수하려면 올바른 제어 및 도구를 갖추고 있어야 합니다. 대부분의 조직에서 SOC 2 규정 준수를 잃는 것은 선택 사항이 아니지만, 올바른 도구를 사용하면 규정 준수를 유지하고 향후 감사에서 지속적인 규정 준수를 용이하게 할 수 있습니다.
콘텐츠

SOC 2에 대한 간략한 개요
현재 SOC 규정 준수를 검토 중인 조직에게는 고려해야 할 정보의 양이 너무 많을 수 있습니다. 모든 것을 점검해야 하는 것처럼 보일 수도 있습니다. 대부분의 조직은 SOC 2 또는 SOC 3 규정 준수를 위해 노력합니다. SOC 2와 SOC 3 규정 준수의 주요 차이점은 SOC 3 감사 보고서가 공개적으로 제공된다는 것입니다. 두 유형에 대한 요구 사항은 동일하지만 SOC 3는 일반적으로 제공업체 사이트에 공개적으로 배포됩니다. 예를 들어 Google의 클라우드 플랫폼은 SOC 3를 준수하며 해당 사이트에서 보고서를 읽을 수 있습니다.
SOC 2 감사는 조직의 데이터 보안 능력과 고객 데이터의 지속적인 가용성 및 무결성을 보장하는 데 사용되는 제어에 중점을 둡니다. 감사의 다섯 가지 주요 원칙은 다음과 같습니다:
- 개인정보 보호: 조직에서 액세스 제어, 다단계 인증(MFA), 암호화를 사용하여 데이터 프라이버시를 유지하고 암호화 보안을 위한 FIPS 140-3 준수와 같은 표준을 준수하고 있나요?
- 보안: 방화벽, 침입 탐지 및 MFA를 사용하여 공격자가 데이터에 액세스하지 못하도록 차단하고 있나요?
- 가용성: 인프라에 성능 모니터링, 재해 복구, 인시던트 관리 기능이 포함되어 있나요?
- 처리 무결성: 소프트웨어 개발 수명 주기(SDLC) 및 변경 제어에 품질 보증 및 프로세스 모니터링이 포함되어 있나요?
- 기밀성: 데이터 저장소에 권한이 없는 사용자로부터 보호하기 위한 암호화, 액세스 제어 및 방화벽이 포함되어 있나요?
SOC 2 규정 준수는 다른 규정 준수 표준과 같은 인증이 아닙니다. 이는 높은 수준의 데이터 보안 및 가용성 표준을 충족하는지 확인하기 위해 현재 절차와 인프라를 감사하는 것입니다.
SLA 표준 충족
사이버 보안 인프라를 검토하고 보강하는 데 급급하다 보면 서비스 수준 협약(SLA) 표준을 간과하는 경우가 많습니다. SLA는 고객에게 하는 약속이며, 이러한 약속은 계약에 따른 것으로 반드시 지켜야 합니다. 예를 들어 고객에게 중간 수준의 문제에 대해 5일의 해결 시간을 제공했다면 그 기간 내에 문제를 해결해야 하며, 그렇지 않으면 SLA 목표를 놓치게 됩니다.
KernelCare에서 우리는 고객인 동시에 공급자입니다. 고객에게 서비스를 제공하지만 내부 IT 직원은 내부 직원을 지원하고 자체 표준과 내부 직원과의 약속에 따라 정해진 SLA를 충족해야 합니다. 고객이자 공급자이기도 한 우리는 SLA를 충족하는 것의 중요성과 합리적인 기대치를 설정하는 것의 중요성을 잘 알고 있습니다.
SLA는 협상할 수 있지만 일단 계약이 체결되면 조직은 SLA 요구 사항을 충족하기 위해 노력해야 합니다. SLA 요구 사항 및 메트릭은 일반적으로 티켓팅 시스템과 같은 내부 애플리케이션에서 추적됩니다. 이러한 SLA 요구 사항 중 하나는 가동 시간이며 가용성에 대한 SOC 2 감사 원칙을 다룹니다.

규정 준수 여부를 판단하기 위한 추적 지표
규정 준수를 위해 노력하는 조직의 경우, 첫 번째 단계 중 하나는 보고서를 실행하고 핵심 성과 지표(KPI) 형태의 지표를 수집하는 것입니다. KPI는 모든 IT 시스템에서 여러 가지 지표를 측정하는 데 사용됩니다. KPI를 통해 우수한 부분과 개선의 여지가 있는 부분을 파악할 수 있습니다. 또한 더 나은 전략에 집중하고 병목 현상을 제거해야 할 부분을 알려줄 수도 있습니다.
SOC 2 규정 준수에 사용되는 일반적인 KPI는 가동 시간 측정입니다. 가동 시간(또는 시스템 가동 시간)은 연중 시스템을 사용할 수 있는 시간을 의미합니다. 시스템은 서버, 네트워킹 장비 또는 스토리지일 수 있습니다. 서비스를 오프라인으로 전환하고 재부팅이 필요한 예정된 유지보수를 포함하여 모든 다운타임은 이 지표에 영향을 미칩니다.
우수한 가동 시간 가용성 평가를 받기 위해 서비스 제공업체는 9점을 받기 위해 노력합니다. 가동 시간 비율에서 9가 많을수록 공급업체가 고객에게 더 나은 품질의 가동 시간과 가용성을 제공할 수 있습니다. 예를 들어, 매년 52.60분의 다운타임만을 약속할 수 있는 조직은 가용성 또는 가동 시간 비율이 99.99% 또는 4.9입니다. 다운타임 수치가 낮을수록 가동 시간 비율이 높습니다. 모든 조직은 100%를 위해 노력하지만 현실에서는 단 몇 밀리초라도 예기치 않게 서비스를 중단시키는 문제가 발생하기 때문에 모니터링, 알림 및 직원의 대응은 문제 해결 SLA에 매우 중요합니다.
가동 시간만이 규정 준수 검토에 사용되는 유일한 지표는 아닙니다. 일반적으로 조직에는 현재 절차의 효율성을 판단하기 위해 따르는 몇 가지 KPI가 있습니다. 몇 가지 다른 메트릭은 다음과 같습니다:
- 심각도 수준(예: 높음, 중간, 낮음)별로 구분된 CVE(공통 취약성 노출)에 취약한 것으로 밝혀진 애플리케이션의 수입니다.
- 운영 체제를 포함한 취약한 소프트웨어를 패치하는 데 걸리는 평균 시간
- 서비스별 가용성
- 호스트 또는 네트워크 부하 및 지연 시간
다른 지표에 영향을 미치는 KPI
어떤 경우에는 상충되는 KPI가 있어 상황을 판단하기 어렵게 만드는 경우도 있습니다. 일반적인 KPI는 악명 높은 '취약성 격차'로, 스캔을 통해 소프트웨어가 취약하거나 오래된 것으로 확인된 후 시스템을 패치하는 데 걸리는 시간입니다. 이 격차는 시간이 지날 때마다 시스템이 패치되지 않을 때마다 증가합니다.
패치 적용을 지연하는 조직은 이 지표가 규정 준수에 비해 너무 높다고 생각할 수 있습니다. 일반적으로 패치는 매월(또는 매주) 특정 날짜로 예정되어 있습니다. 문제는 이제 취약점이 공개적으로 알려져 있고 일부는 익스플로잇 코드와 함께 발표된다는 것입니다. 소프트웨어 업데이트가 지연되면 서버는 취약한 상태로 남아 익스플로잇에 노출됩니다. 2019년 데이터 유출 사고의 60%는 패치가 가능한 취약점으로 인해 발생했습니다.
하나의 KPI 지표가 다른 지표에 영향을 미쳐 여러 목표에 차질을 빚을 수 있습니다. 예를 들어, 취약성 격차와 패치 적용으로 인해 서버를 재부팅해야 하는 경우 가동 시간에 영향을 미칠 수 있습니다. 매일 새로운 CVE가 발표되고 패치가 배포되기 때문에 조직이 이를 따라잡고 재부팅을 피하는 것이 어려워져 SLA에 영향을 미치는 다운타임이 발생할 수 있습니다. 예를 들어 30일 이내에 시스템을 패치해야 하고 예정된 패치 세션마다 재부팅이 필요한 경우 가동 시간 비율이 낮아집니다.
규정 준수를 위한 도구
규정 준수를 충족하고 SLA 요건을 준수하기 위한 좋은 전략은 자동화를 사용하는 것입니다. 자동화를 통해 많은 문제를 심각한 침해나 규정 위반으로 이어지기 전에 감지할 수 있습니다. 또한 패치 적용과 같은 일부 문제를 해결하는 데도 사용할 수 있습니다. 패치 관리 자동화 도구는 시중에 나와 있는 많은 취약점 스캔 도구와 잘 통합되므로 취약점 격차를 개선하기 위해 함께 사용할 수 있습니다.
취약점을 수동으로 패치하는 경우 관리자에게는 부담이 될 수 있습니다. 관리자는 보고서를 읽고, 적합한 소프트웨어 버전을 결정하고, 패치를 테스트한 다음 프로덕션 환경에 배포해야 합니다. 수백 대의 서버를 보유한 조직의 경우 패치 관리를 전담하는 팀 전체가 필요합니다. 자동화 도구를 사용할 수 있는 경우 이러한 시스템은 조직의 리소스 낭비가 될 수 있습니다. 규정 준수 자동화 도구는 수동 패치 대신 시간과 리소스를 절약하는 동시에 진화하는 감사 요건을 충족하는 데 도움이 됩니다.
다음은 모든 서버에서 SOC 2 규정 준수를 충족하고 보안을 개선하기 위해 KernelCare가 사용하는 몇 가지 IT 규정 준수 도구입니다:
- 테너블 네서스: 네서스는 시중에서 가장 인기 있는 취약점 스캐너 중 하나입니다. 네트워크를 스캔하여 패치되지 않은 소프트웨어를 포함한 취약점을 찾아냅니다.
- Ivanti: Ivanti는 에셋을 검색하고 패치 자동화를 관리합니다.
- KernelCare: 자체 제품을 사용하여 타사 라이브러리 및 Linux 커널을 포함한 소프트웨어 패치를 유지합니다. 소프트웨어를 자동으로 패치할 뿐만 아니라 KernelCare는 재부팅이 필요 없는 솔루션으로, 패치 후 서버를 재부팅할 필요가 없습니다. 이 서비스는 재부팅으로 인한 가동 중단 시간 손실 없이 가동 시간 지표를 최대한 높게 유지합니다.
결론
규정을 준수하려면 서버를 최신 취약성 패치로 업데이트해야 하지만, 가동 시간 SLA를 유지하는 것도 중요합니다. 이 두 가지가 충돌하면 조직이 올바른 도구를 찾고 모든 요구 사항을 충족하는 절차를 개발하기 어려울 수 있습니다. 재부팅 없는 패치를 포함한 자동화를 통해 조직은 높은 가동 시간을 유지하면서 취약한 시스템을 30일 이내에 패치할 수 있습니다. 결과적으로 이러한 도구를 사용하면 감사를 받은 후 SOC 2 규정 준수에 훨씬 더 가까워질 수 있습니다.



