#서비스기획 - 기획자가 챙겨야 할 ISMS 인증

ISMS chatGPT

보안은 개발만의 일이 아니다.

 

✅ 왜 기획자가 ISMS를 알아야 할까?

기획자는 '보안'이라는 단어를 들으면 뒤로 물러서게 된다.

하지만 서비스 흐름, 데이터 구조, 개인정보 입력/보관/삭제 등

보안 리스크의 진입점은 대부분 기획자가 설계한 플로우에서 시작된다.

 

그래서 ISMS는 개발팀이나 보안팀만의 일이 아니다.

기획자가 알아야 하는 구조와 기준이 있다.

 

🔍 ISMS란 무엇일까?

ISMS(Information Security Management System)는 정보보호 관리체계를 뜻하며,

기업이 보유한 정보자산(개인정보 포함)을 지속적이고 체계적으로 보호하기 위한 기준을 말한다.

KISA(한국인터넷진흥원)에서 심사와 인증을 진행한다.

 

ISMS 인증 대상(2024년 기준)

구분	기준 요건
인터넷서비스 사업자	다음 중 하나라도 해당되면 의무 대상  1) 전년도 매출액 100억원 이상  2) 저년도 일일 평균 이용자 수 100만명 이상
전자상거래 사업자	연간 매출액 10억원 이상 + 회원수 100만명 이상
클라우드 서비스 사업자	월 매출액 5천만원 이상 + 월 이용 고객 1천명 이상
정보통신망법 상 의무 사업자	정보통신서비스 제공자 중 일정 기준 충족 시 (방통위 고시 기준)
기타	공공기관, 대기업 계열사, 금융기관 등 자체 또는 계약상 의무로 요구되는 경우

 

ISMS 심사 및 인증 주기

구분	내용
최초 인증 심사	인증을 처음 취득할 때 64개 통제항목 전체에 대해 심사 진행
유효기간	3년
사후관리 심사	매년 1회 실시. 주요 항목 이행 여부, 변경사항 반영 여부 점검
갱신 심사	3년 단위로 전체 심사를 다시 받아야 함(최초 심사와 유사)

 

ISMS 구성 요약

구분	핵심 내용
관리적 보호조치	정책 수립, 조직 역할 정의, 위험관리 프로세스
기술적 보호조치	접근 통제, 암호와, 로그관리, 백업, 보안패치
물리적 보호조치	서버 접근 통제, 출입관리, 장비 보안 등

 

📌 기획자가 고려해야 할 5가지 ISMS 관점 포인트

항목	질문	기획자가 해야 할 체크
1. 인증/로그인 정책	비밀번호 길이, 변경 주기, OTP는 필요한가?	회원가입 및 로그인 플로우에 기준 반영되어 있는가?
2. 개인정보 흐름	수집 -> 저장 -> 제공 -> 폐기까지 흐름은?	서비스 흐름도 상에서 데이터 lifecycle을 그릴 수 있는가?
3. 권한 구조	운영자, 고객센터, 외부 수탁업체 권한 구분은?	관리자 기능 설계 시 '최소 권한 원칙'이 반영되었는가?
4. 로그 기록	누가 언제 어떤 데이터를 조회했는가?	기능 단위로 로그를 남기고 있는가? 저장 기간은?
5. 예외 상황/에러 처리	실패 시 사용자/운영자에게 어떻게 안내할 것인가?	에러 발생 시 무슨 로그를 남기고 누구에게 알릴 것인가?

 

개인정보 처리방침은 어떤 정보를 얻고자 하는지, 왜 필요한지에 대한 명시

회원에게 얻고자 하는 정보에 대한 명시와 범위를 설정해야 한다.

또한, 각 정보를 획득하는 목적도 분명해야 한다.

이러한 내용은 개인정보 처리방침 내 모두 표기가 되어야 하는데.

표기하는 내용은 시행령에 따라 바뀐다.

 

소셜 로그인을 제공하는 업체일 경우, 각 SNS 채널에서 제공하는 정보값이 상이하다.

채널에 따라서도 기본적으로 제공하는 데이터가 있는 반면에.

목적이 불분명한 데이터는 채널에서 제공하지 않는다.

 

이러한 내용을 반영하여 선택값과 필수값에 대해서 구분하여 표시해야한다.

 

회원정보 도메인은 철저한 보안이 될 수 있도록 설계

마이페이지 내 영역은 직접 로그인한 디바이스에서만 접근이 가능하도록 설계되어야 한다.

때로 ULR로 직접 접근 했을 경우, 가능한 경우가 있는데 절대 되어서는 안된다.

이외에도 여러 경로를 통해 접근을 했을 때 보안에 이슈가 없도록 조치되어야만 한다.

 

예외 처리에 대한 방어 로직 필요

의도적으로 서버를 불안정하게 만들고자 하는 공격을 대응할 수 있는 로직 설계도 필요하다.

짧은 시간 내에 로그인 시도 횟수를 무한하게 시도한다거나.

의도적으로 이메일 인증, 문자번호 인증 등 인증을 수 없이 시도한다거나.

 

일반적인 사용자가 아닌 사용자가 시도하는 경우에 대해서도 방어로직이 필요하다.

 

획득한 정보에 대한 파기 절차 수립

회원이 탈퇴하였을 경우, 보관기간과 파기 절차에 대해서도 정리되어 있어야 한다.

그리고 파기 후 파기된 내용과 방법 시점에 대해서도 기록되어야 한다.

 

개인정보 관리 내부 방침

획득한 개인정보 관리는 권한과 절차에 따라 보안이 지켜져야만 한다.

특히 쇼핑몰일 경우 회원 정보에 구매내역을 비롯한 개인정보가 많다.

해당 정보는 내부 방침에 따라 보관되어야 하며 내부적으로 정해진 사람만이 권한을 갖고 관리해야 한다.

 

개인정보 외주사/수탁사 계약서 보안 조항

쉽게 놓칠 수 있는 부분 중 하나이다. 내부 처리방침에 대해서만 잘 관리되어서는 안된다.

외주사/수탁사와의 계약서 상에도 보안 조항에 대해 명시 및 관리되어야 한다.

 

본인인증 서비스나 쿠폰 제휴 서비스가 이에 해당된다.

해당 업체에 위 개인정보 처리방침에 대한 서류가 있으니 요청해서 받으면 된다.

 

---

 

ISMS를 단순 운영 업무로 생각할 수도 있다.

하지만 최근 SKT 사태를 보면 누군가의 안일한 태도가 큰 사고로 이어진 것을 볼 수 있다.

누군가 챙기겠지. 나는 아니겠지. 개발에서 하겠지.라는 방어적인 태도로 하면 안된다.

 

되려 전반적인 서비스의 데이터 흐름과 사용자 생애를 파악할 수 있는 좋은 기회로 여기자.

나아가 개선 포인트까지 짚어낼 수 있다면 더할 나위 없이 좋은 시간이다.

 

가장 기본적인 것이 가장 중요하다.

내가 생각지 못한 곳곳에 예외 케이스는 언제나 존재한다.

나의 작은 관심과 고민이 어떤 사용자에게는 감동을 줄 수 있길 바래본다.