보안 관리·인증

‘관리체계 읽기’ 묶음의 한 편 · 5 / 7 — 처음부터 읽기 →

외주에 맡긴 일의 보안은 누가 챙기나: 위탁·공급망 관리의 구조

개발을 맡기고, 운영을 위탁하고, 만들어진 소프트웨어를 들여오는 순간 보안의 경계는 회사 담장 밖으로 넓어집니다. 그 넓어진 경계를 관리하는 틀을 정리합니다.

짧은 답

외주 개발, 위탁 운영, 도입 솔루션도 모두 보안의 경계 안에 들어와요. 선정·계약·운영·종료 네 단계마다 확인할 것을 정하고, 자주 비는 재위탁 파악과 종료 후 계정 회수부터 챙기세요. 시작은 목록 한 장이에요.

공장 건물 세 채가 컨베이어 벨트로 이어지고, 그 사이 검사 게이트가 지나가는 상자를 조명으로 비추는 모습
이 글의 차례 7

사고는 담장 밖에서도 들어온다

우리 회사 시스템은 잘 챙기고 있는데, 외주 업체나 위탁사 쪽은 어디까지 봐야 하는지 애매하시죠. 계약서에 뭘 넣어야 할지, 점검은 어디까지 해야 할지 기준이 없으면 손을 대기가 어려워요. 이 글에서는 넓어진 경계를 네 단계로 나눠 관리하는 틀을 정리해 드릴게요.

보안을 처음 공부할 때는 자연스럽게 우리 회사의 서버, 우리 직원의 계정, 우리 사무실의 출입문을 떠올리게 돼요. 근데 말이죠, 요즘 조직의 일은 상당 부분 담장 밖에서 이뤄져요. 홈페이지 개발은 외주 업체가 맡고, 고객 상담은 위탁 콜센터가 받고, 급여 계산은 외부 서비스가 처리하고, 업무 시스템은 다른 회사가 만든 소프트웨어를 들여와 써요. 편리하고 효율적인 방식이고, 앞으로도 더 늘어날 흐름이에요.

보안의 경계가 그만큼 넓어진다는 점이 문제예요. 우리 시스템이 아무리 잘 관리되어도, 우리 데이터에 접근할 수 있는 협력사의 계정이 뚫리면 결과는 우리 사고가 돼요. 실제로 침해사고 소식을 따라가 보면 공격이 대상 조직을 직접 두드리는 대신, 그 조직과 연결된 협력사나 공급된 소프트웨어를 거쳐 들어오는 구조가 자주 등장해요. 다행인 건 이 위험이 관리 불가능한 종류가 아니라는 점이에요. 경계가 어디까지 넓어졌는지 파악하고 단계별로 확인할 것을 정해 두면, 담장 밖의 위험도 충분히 다룰 수 있는 대상이 돼요.

위탁과 공급망, 비슷해 보이지만 성격이 다르다

바깥과 연결되는 방식은 크게 세 갈래로 나눠 보면 정리가 쉬워요. 첫째는 업무 위탁이에요. 고객 상담, 배송, 마케팅 대행처럼 우리 업무의 일부를 다른 회사가 대신 수행하는 형태로, 개인정보가 함께 넘어가는 경우가 많아 개인정보보호 법령도 위탁 관계에 대한 요구사항을 별도로 두고 있습니다. 세부 의무는 법령 개정에 따라 달라질 수 있으니 개인정보보호위원회의 공식 안내에서 현재 기준을 확인하는 편이 정확합니다.

둘째는 IT 외주예요. 시스템 개발·운영·유지보수를 외부 인력이 맡는 형태인데, 이분들은 우리 시스템 내부에 접근 권한을 가진 채 일해요. 권한의 깊이가 깊은 만큼 계정과 접근 통제가 관리의 중심이 돼요. 셋째가 좁은 의미의 공급망이에요. 우리가 들여와 쓰는 소프트웨어, 그 소프트웨어가 내려받는 업데이트, 개발에 쓰이는 외부 라이브러리처럼 '만들어진 것'이 흘러 들어오는 경로예요. 이쪽은 계약서보다 도입 검토와 업데이트 경로 관리가 핵심이 되고요. 세 갈래 모두 '바깥과 연결되어 있다'는 공통점이 있지만 위험의 성격과 챙길 지점이 다르다는 걸 구분하는 순간, 관리가 한결 구체적으로 보이기 시작해요.

선정에서 종료까지: 관리의 네 단계

'위탁 관리의 네 단계'. 선정은 보안 수준 확인, 계약은 요구사항·사고 통지, 운영은 최소 권한·점검, 종료는 권한 회수·자료 파기

위탁 관리는 계약서에 도장을 찍는 순간이 아니라 상대를 고르는 순간부터 시작돼요. 선정 단계에서는 맡기려는 일의 민감도에 맞춰 상대의 보안 수준을 확인해요. 중요한 데이터를 다루는 위탁이라면 보안 조직이 있는지, 관리체계 인증을 운영하는지, 사고 이력에 어떻게 대응했는지 같은 질문이 선정 기준에 들어가는 게 자연스러워요. 계약 단계에서는 확인한 내용을 문서로 고정해요. 보안 요구사항, 사고 발생 시 통지 의무, 재위탁을 할 때의 조건, 종료 시 자료 처리 방식이 계약서에 적혀 있어야 나중에 기댈 근거가 생겨요.

운영 단계는 가장 길고 가장 느슨해지기 쉬운 구간이에요. 외주 인력의 계정에 필요한 만큼만 권한을 주고, 인력이 바뀌면 계정도 함께 정리하고, 약속한 보안 수준이 지켜지는지 주기적으로 점검하는 일이 여기 들어가요. 마지막이 종료 단계예요. 계약이 끝나면 발급했던 계정과 접근 권한을 회수하고, 넘겨줬던 자료가 반환되거나 파기되었는지 확인해요. 네 단계를 한 번에 완벽하게 갖추실 필요는 없어요. 우리 조직이 지금 어느 단계를 비워 두고 있는지 아는 것만으로도 방향이 잡히고, 하나씩 채워 갈 때마다 확실히 든든해지는 걸 느끼실 수 있어요.

현장에서 자주 비는 칸

일반적으로 가장 자주 비어 있는 칸은 재위탁 파악이에요. 우리가 일을 맡긴 회사가 그 일의 일부를 다시 다른 회사에 맡기는 경우가 드물지 않은데, 두 번째 회사부터는 우리 시야에서 사라지기 쉬워요. 계약서에 재위탁 시 사전 동의나 통지를 조건으로 넣어 두시면, 보이지 않던 연결 고리가 문서 위로 올라와요. 다음으로 자주 비는 칸은 종료 후 계정이에요. 찔리시는 분 계시죠? 프로젝트가 끝났는데 외주 인력의 계정이 살아 있는 상황은 현장에서 흔히 발견되는 패턴이에요. 계약 종료 절차에 계정 회수를 항목으로 넣어 두는 것만으로 예방이 되는, 비용이 거의 들지 않는 개선이고요.

점검이 형식이 되는 경우도 있어요. 협력사에 점검표를 보내고 서명을 받아 보관하는 것으로 점검을 마쳤다고 여기는 방식인데, 문서 왕복만으로는 실제 운영을 보기 어려워요. 모든 협력사를 깊이 점검할 수는 없으니, 다루는 데이터의 민감도와 접근 권한의 깊이에 따라 등급을 나눠 중요한 곳에 확인의 깊이를 더하는 방식이 현실적이에요. 이렇게 우선순위를 정해 두면 한정된 시간으로도 의미 있는 점검이 가능해지고, 담당자 입장에서도 '다 못 봤다'는 부담 대신 '중요한 곳은 확실히 봤다'는 안심을 얻을 수 있어요.

작은 조직이 시작하는 법: 목록 한 장부터

'목록 한 장부터 시작해요' 체크리스트. 어떤 회사에 무슨 일을 맡기는지, 쓰는 외부 서비스, 데이터가 닿는 범위부터 적기

전담 조직이 없는 작은 회사라면 이 모든 이야기가 부담스럽게 들릴 수 있어요. 그럴수록 시작을 작게 잡으시는 게 좋아요. 방법은 간단해요. 첫걸음은 목록 한 장이에요. 우리가 어떤 회사에 어떤 일을 맡기고 있는지, 어떤 외부 서비스와 소프트웨어를 쓰고 있는지, 각각이 우리 데이터에 어디까지 접근하는지를 표로 적어 보세요. 직접 만들어 보면 생각보다 연결이 많다는 사실에 놀라게 되고, 동시에 무엇부터 챙겨야 할지가 자연스럽게 보이기 시작해요.

목록이 생기면 그다음은 순서대로예요. 민감한 데이터를 다루는 위탁부터 계약서에 보안 조항이 있는지 확인하고, 외부 인력 계정의 권한과 생존 여부를 점검하고, 계약 종료 시 확인할 항목을 짧은 절차로 만들어 두시면 돼요. 하나하나는 반나절이면 할 수 있는 일이지만, 쌓이면 조직의 보안 수준을 실질적으로 끌어올려요.

이제 이렇게 하시면 돼요. 오늘은 목록 한 장을 만들고, 이번 주에는 가장 민감한 위탁 한 건의 계약서와 계정만 확인해 보시면 돼요. 위탁·공급망 관리는 협력사를 의심하는 일이 아니라, 함께 일하는 관계를 오래 건강하게 유지하는 장치에 가까워요. 경계가 넓어진 만큼 관리의 틀도 함께 넓혀 두면, 바깥과 연결된 편리함을 훨씬 가벼운 마음으로 누리실 수 있어요. 한 번 목록을 만들어 두면 다음부터는 새 업체가 생길 때 한 줄 추가하는 일로 끝나요. 그렇게 유지되는 목록 하나가 결국 담장 밖까지 챙기는 조직과 그렇지 않은 조직을 가르는 차이가 돼요.

자주 묻는 질문

외주·위탁 업체 보안 관리는 어디서부터 시작하면 되나요?

목록 한 장부터 시작하시면 돼요. 어떤 회사에 무슨 일을 맡기고 있는지, 어떤 외부 서비스를 쓰는지, 각각이 우리 데이터에 어디까지 닿는지를 표로 적어 보시면 무엇부터 챙길지가 저절로 보여요. 그다음은 민감한 위탁 한 건의 계약서와 계정만 확인해 보시면 첫 걸음으로 충분해요.

개인정보 처리를 위탁하면 법적 책임도 함께 넘어가나요?

위탁을 했다고 해서 맡긴 쪽의 관리 책임이 사라지는 구조는 아닙니다. 개인정보보호 법령은 위탁하는 쪽에도 문서화·관리·감독 같은 역할을 요구해요. 다만 구체적인 의무의 범위와 요건은 법령 해석과 개정에 따라 달라질 수 있으므로, 개별 사안의 판단은 개인정보보호위원회의 공식 안내나 전문가 상담으로 확인하는 것이 정확합니다.

협력사가 보안 점검을 부담스러워하면 어떻게 하나요?

점검을 감사나 추궁의 틀로 가져가면 관계가 경직되기 쉬워요. 계약 단계에서 점검의 범위와 방식을 미리 합의해 두고, 운영 중에는 상대가 이미 갖춘 인증이나 자체 점검 결과를 활용하면 부담을 크게 줄일 수 있어요. 서로의 보안 수준을 확인하는 일이 양쪽 모두를 지키는 장치라는 공감대가 만들어지면 협조는 자연스럽게 따라와요.

오픈소스 라이브러리도 공급망 관리 대상인가요?

맞아요. 개발에 쓰이는 외부 라이브러리는 계약서가 없을 뿐, 만들어진 코드가 흘러 들어오는 공급망 경로예요. 어떤 라이브러리를 쓰고 있는지 목록을 유지하고, 알려진 취약점 정보가 나왔을 때 우리가 영향을 받는지 확인할 수 있는 상태를 만드는 게 관리의 출발점이에요. 도구와 방법은 개발 환경마다 다르니, 우리 팀의 빌드 과정에서 자연스럽게 확인되는 방식을 찾는 편이 오래가요.

직접 확인해 보실 곳

확인할 곳

이 글에서 다루는 주제를 맡는 공식 기관입니다. 신고·상담 창구도 여기에 있으니, 실제 상황에서는 아래로 바로 이어 가시면 됩니다.

이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.

이 글의 용어

보안 용어 사전에서 한 줄 정의와 쉬운 비유로 다시 볼 수 있어요.