Cybersecurity

회사의 웹 애플리케이션 보안, 해킹당하기 전에 왜 필요할까요?

공유하기!
매장 사장님이 휴대폰으로 자물쇠와 보안 경고가 뜬 웹 앱 관리 화면을 보고 있는 모습

네, 회사의 웹 앱에는 첫날부터 사이버 보안이 필요합니다

사업을 돕는 웹 앱이 있다면 답은 분명합니다. 웹 애플리케이션 보안은 앱이 멈추지 않게 하고, 고객의 데이터가 도난당하지 않도록 지켜 줍니다. 웹 앱은 브라우저에서 돌아가는 프로그램입니다. 온라인 쇼핑몰, 예약 시스템, 학생들이 로그인하는 포털 같은 것들입니다. 이 프로그램은 하루 종일 인터넷에 열려 있어서, 인터넷에 연결된 누구나 문을 두드릴 수 있습니다. 사이버 보안은 낯선 사람이 들어오지 못하게 막고, 침입 시도를 알아채고, 문제가 생겼을 때 업무를 빨리 되살리는 조치들의 묶음입니다.

저희 생각은 분명합니다. 해킹을 당한 뒤에야 보호를 고민해서는 안 됩니다. 해킹이란 권한이 없는 사람이 시스템에 들어와 데이터를 읽거나, 바꾸거나, 시스템을 멈추게 하는 것입니다. 피해가 난 뒤 복구하려면 며칠에서 몇 주 동안 일이 멈추고, 일부 고객의 신뢰는 다시 돌아오지 않을 수도 있습니다. 처음부터 만들어 둔 보호는 뒤에서 조용히 일하고, 고객은 그저 안심된다는 느낌으로만 알아챕니다.

사업 규모가 작아도 상관없습니다. 웹사이트로 약을 파는 약국 사장님, 환자 기록을 관리하는 병원 실장님, 성적을 온라인에 올리는 학교 교장 선생님 모두 해커에게 가치 있는 데이터를 갖고 있습니다. 피해를 입는 곳과 무사한 곳의 차이는 대개 제때 해 둔 간단한 조치입니다. 안전한 로그인, 제때 하는 업데이트, 그리고 실제로 확인해 본 백업입니다. 다음 내용에서 이 조치들을 쉬운 말로 설명합니다. 낯선 용어가 나오면 용어 사전에서 뜻을 찾아보실 수 있습니다.

해커는 왜 작은 회사까지 노릴까요?

많은 사업주가 해커는 은행이나 대기업만 노린다고 생각합니다. 이런 생각 때문에 보호를 해마다 미루게 됩니다. 사실 작은 회사는 손쉬운 목표입니다. 보호가 대체로 약하고, 사장님이 시스템에서 무슨 일이 일어나는지 지켜보지 않기 때문입니다.

가게가 열 곳 있는 거리를 떠올려 보세요. 도둑은 가장 부자인 가게가 아니라 문을 열어 둔 가게를 고릅니다. 인터넷에서도 똑같은 일이 일어납니다. 다른 점은 이곳의 도둑은 짧은 시간에 수천 개의 문을 시험해 본다는 것입니다.

공격은 자동으로 이루어지고, 이름을 보고 고르지 않습니다

대부분의 공격은 누군가 일부러 내 웹사이트 앞에 앉아서 하는 것이 아닙니다. 봇이라고 부르는 자동 프로그램이 웹사이트를 하나씩 돌아다니며 합니다. 이 프로그램들은 쉬운 비밀번호를 받아 주는 로그인 페이지나, 이미 알려진 약점이 있는 오래된 프로그램을 찾습니다.

열린 문을 찾으면 회사의 크기나 이름은 묻지 않고 그냥 들어옵니다. 그래서 조용한 동네의 작은 병원도 큰 웹사이트와 똑같은 공격 시도를 받습니다. 중요한 질문은 누가 들어오려고 할지가 아니라, 들어오려 할 때 문이 잠겨 있을지입니다.

내 데이터는 다른 사람에게 가치가 있습니다

고객 목록에서 특별한 점을 못 느끼실 수도 있지만, 해커에게는 보물입니다. 고객의 이름, 전화번호, 주소는 팔리고, 사기 메시지에 쓰입니다. 환자 기록, 학생 성적, 직원 정보는 주인을 협박하는 데 쓰일 수 있는 민감한 정보입니다.

아무것도 훔치지 않는 공격도 있습니다. 파일을 잠가 버리고 풀어 주는 대가로 돈을 요구하는 것입니다. 이것을 랜섬웨어라고 하며, 제대로 된 백업이 없는 회사를 노립니다. 이 경우 파일을 하나도 도난당하지 않았더라도, 멈춰 있는 하루하루가 그대로 손실이 됩니다.

해킹이 남기는 피해는 이렇습니다

해킹 이야기는 다음 날 아침에 무슨 일이 벌어지는지 보기 전까지는 남의 일처럼 들립니다. 피해는 기기 하나나 파일 하나에서 끝나지 않고 고객, 직원, 평판까지 번집니다. 이 피해를 자세히 알면 보호의 가치를 현실적으로 판단할 수 있습니다.

아래 예시는 과장이 아닙니다. 준비 없이 앱이 해킹당했을 때 사업주가 실제로 겪는 일입니다. 모두 뒤에서 소개할 잘 알려진 방법으로 막거나 피해를 줄일 수 있습니다.

고객 데이터가 손을 떠납니다

가장 먼저 일어나는 일은 대개 데이터 유출입니다. 볼 권리가 없는 사람에게 데이터가 넘어가는 것입니다. 온라인 쇼핑몰이라면 고객의 주소, 전화번호, 구매 기록이 새어 나갈 수 있습니다. 그 뒤 고객들은 내 쇼핑몰 이름을 단 가짜 메시지를 받고, 카드 정보나 휴대폰으로 받은 인증번호를 요구받게 됩니다.

고객은 해커와 사장님을 구별하지 못합니다. 메시지에 사장님 가게 이름이 적혀 있기 때문입니다. 그래서 쇼핑몰 시스템 자체가 처음부터 잘 보호되어 있어야 합니다. 판매, 재고, 고객 데이터를 보호된 한곳에 모아 관리하는 Storek 매장 관리 시스템처럼요.

업무가 가장 나쁜 때에 멈춥니다

공격은 한가한 날을 고르지 않습니다. 명절 대목, 학교 입학 신청 주간, 병원 예약이 꽉 찬 날에 웹사이트가 멈출 수 있습니다. 가장 잘 알려진 공격 중 하나는 웹사이트에 엄청난 양의 요청을 보내 응답하지 못하게 만드는 것입니다. 그러면 진짜 고객이 사이트에 들어올 수 없습니다.

멈춘 동안에는 새 주문이 들어오지 않고, 화가 난 고객의 전화가 이어지고, 직원들은 일 대신 사과에 매달립니다. 문제가 단순한 접속 폭주가 아니라 해킹이라면, 조사와 정리, 안전한 재가동이 끝날 때까지 시스템이 며칠 동안 닫혀 있을 수도 있습니다.

신뢰를 잃고, 법적인 문제가 따라올 수도 있습니다

내 웹사이트에서 데이터를 도난당한 고객은 그 일을 오래 기억합니다. 조용히 떠나는 고객도 있고, 소셜 미디어에 경험을 올리는 고객도 있습니다. 검색 엔진이 해킹된 사이트 옆에 경고를 띄울 수도 있어서, 새 방문자는 들어오기 전에 망설이게 됩니다.

많은 나라에는 회사가 사람들의 데이터를 보호하도록 정한 법이 있습니다. GDPR로 알려진 유럽의 개인정보 보호 규정이 그 예입니다. 보호를 소홀히 한 회사는 무슨 일이 있었는지 설명하고, 피해자에게 알리고, 필요한 조치를 했다는 것을 증명하라는 요구를 받을 수 있습니다. 모두 피할 수 있었던 서류와 수고와 시간입니다.

웹 앱의 약점은 보통 어디에 숨어 있을까요?

약점, 곧 취약점은 해서는 안 되는 일을 누군가 할 수 있게 만드는 시스템의 작은 실수입니다. 매일 시스템을 쓸 때는 모든 것이 정상처럼 보여서 눈에 띄지 않습니다. 하지만 찾는 사람에게는 금방 보입니다.

저희 경험으로는 취약점이 몇 군데 잘 알려진 곳에서 반복해서 나옵니다. 그곳을 알고 있으면 팀이나 업체에 이름을 들어 물어볼 수 있습니다.

비밀번호 하나로만 하는 로그인

로그인 페이지는 앱의 현관문입니다. 로그인이 비밀번호 하나에만 기대고 있다면, 비밀번호 하나만 훔쳐도 문이 열립니다. 직원들은 쉬운 비밀번호를 고르거나 여러 사이트에서 같은 비밀번호를 쓰는 경우가 많아서, 다른 곳에서 도난당하면 우리 시스템도 함께 열립니다.

잘 알려진 해결책은 여러 단계 로그인입니다. 비밀번호를 입력한 뒤, 시스템이 직원의 휴대폰으로 오거나 휴대폰 앱에 뜨는 코드를 요구합니다. 해커가 비밀번호를 알아도 휴대폰이 없으면 들어올 수 없습니다. 여기에 더해 잘못된 시도가 여러 번 이어지면 계정을 잠시 잠가서, 봇이 수천 개의 비밀번호를 시험하지 못하게 합니다.

업데이트하지 않은 프로그램과 플러그인

모든 웹 앱은 다른 프로그램 위에서 돌아갑니다. 서버의 운영 체제, 프로그래밍 언어, 데이터베이스, 이미 만들어진 플러그인 같은 것들입니다. 서버는 내 웹사이트가 인터넷에서 돌아가는 컴퓨터입니다. 누군가 이 프로그램들에서 취약점을 찾으면 제조사가 그것을 막는 업데이트를 내놓고, 그 취약점의 내용은 해커를 포함해 모두에게 알려집니다.

진짜 위험은 바로 여기에 있습니다. 몇 달 동안 업데이트하지 않은 사이트에는 해커가 이미 들어가는 방법을 알고 있는 공개된 취약점이 남아 있습니다. 그래서 업데이트는 문제가 생겼을 때 떠올리는 일이 아니라, 날짜와 담당자가 정해진 정기 업무여야 합니다. Hostrena 호스팅처럼 관리와 모니터링이 되는 호스팅을 쓰면 서버 쪽의 이 부담을 덜 수 있습니다.

너무 열려 있는 입력 양식과 권한

검색창, 문의 양식, 파일 업로드 칸은 방문자가 원하는 대로 글을 쓸 수 있는 곳입니다. 시스템이 입력된 내용을 확인하지 않으면, 해커는 글 대신 명령어를 써 넣어 데이터베이스를 읽거나 바꿀 수 있습니다. 이것은 웹 앱의 가장 위험한 약점을 모은, 세계적으로 알려진 목록인 OWASP Top 10에서도 가장 유명한 실수 중 하나입니다.

너무 넓게 열린 권한도 비슷한 위험입니다. 병원 접수 직원은 환자 기록을 지울 필요가 없고, 쇼핑몰에서 상품을 등록하는 직원은 전체 상품의 가격을 바꿀 필요가 없습니다. 모든 계정이 업무에 필요한 것보다 많은 권한을 갖고 있으면, 어떤 계정이 도난당하든 작은 문제가 아니라 큰 사고가 됩니다.

모든 앱에 넣는 기본 보호 단계

좋은 보호는 자물쇠 하나에 기대지 않습니다. 여러 겹이 차례로 쌓여 있어서, 해커가 한 겹을 넘어도 다음 겹이 앞을 막습니다. 잠긴 문, 카메라, 그리고 안에 금고가 있는 집과 같습니다.

Linkysoft에서는 이 보호 단계를 프로그래밍이 끝난 뒤가 아니라 기획 단계부터 웹 앱과 관리 시스템 안에 만들어 넣습니다. 이유는 간단합니다. 다 만든 시스템에 나중에 보호를 더하는 것은 처음부터 함께 만드는 것보다 어렵고 오래 걸리기 때문입니다.

암호화는 도난당한 데이터를 쓸모없게 만듭니다

암호화는 올바른 열쇠를 가진 사람만 알아볼 수 있는 기호로 데이터를 바꾸는 것입니다. 저희는 데이터가 오가는 도중, 즉 고객의 기기와 서버 사이를 이동할 때 암호화해서 인터넷에서 누구도 읽지 못하게 합니다. 데이터베이스에 저장되어 있을 때도 암호화합니다.

그 효과는 가장 나쁜 날에 드러납니다. 누군가 데이터베이스 파일에 닿더라도, 고객의 이름과 전화번호 대신 뜻 없는 기호만 보게 됩니다. 암호화 열쇠는 데이터와 떨어진 전용 보관함에 두어서, 열쇠와 데이터를 한꺼번에 훔칠 수 없게 합니다.

직원마다 필요한 것만 봅니다

권한은 업무 역할에 따라 나눕니다. 의사는 자기 환자의 기록을, 회계 담당자는 청구서를, 접수 직원은 예약을 봅니다. 이 방식을 역할 기반 권한이라고 하며, 어떤 실수나 계정 도난이 생겨도 시스템의 작은 부분에만 영향이 미치게 합니다.

이것은 Docmz 병원·의원 관리 시스템이나 아이들의 정보를 다루는 학교 시스템처럼 민감한 데이터가 있는 시스템에서 특히 중요합니다. 여기에 중요한 계정, 특히 권한이 넓은 관리자 계정에는 여러 단계 로그인을 더합니다.

확인된 백업과 모든 작업의 기록

백업은 데이터를 다른 곳에 복사해 둔 것으로, 원본을 잃었을 때 되돌아갈 수 있게 해 줍니다. 하지만 한 번도 확인하지 않은 백업은 정작 필요한 날 소용이 없을 수 있습니다. 그래서 저희는 백업을 암호화해 보호하고, 실제로 복원을 해 보며 필요하기 전에 제대로 작동하는지 확인합니다.

마지막 단계는 감사 로그입니다. 누가, 언제, 무엇을 했는지 적어 두는 기록입니다. 주문이 사라지거나 가격이 바뀌면, 어떤 계정이 몇 시에 그렇게 했는지 기록에서 알 수 있습니다. 이 기록은 해킹을 찾아내는 데 도움이 되고, 직원들 사이의 일상적인 의견 차이를 푸는 데도 도움이 됩니다.

모의 해킹은 우리 팀이 못 보는 것을 어떻게 찾아낼까요?

시스템을 만든 개발자는 그것이 어떻게 돌아가야 하는지 알기 때문에, 오히려 망가뜨리는 모든 방법을 떠올리기 어렵습니다. 모의 해킹이 이 문제를 풉니다. 해커처럼 생각하는 전문가가 미리 합의하고 안전하게 하는 공격입니다. 다만 목표는 취약점을 찾아 다른 누구보다 먼저 사장님께 넘기는 것입니다.

저희는 고객 데이터나 결제를 다루는 앱이라면 출시 전에 반드시 이 테스트를 거쳐야 한다고 봅니다. 이것은 새 시스템과 이미 운영 중인 시스템 모두에 제공하는 저희 사이버 보안 서비스의 핵심입니다.

테스트 중에는 무슨 일이 일어날까요?

전문가는 먼저 사장님과 테스트 범위를 정합니다. 시스템의 어느 부분을, 어느 날에 하고, 무엇은 건드리면 안 되는지입니다. 그다음 진짜 해커가 시도할 만한 것을 웹 페이지, 모바일 앱, 네트워크, 시스템끼리 연결하는 부분에서 시도합니다. 빠르게 훑는 자동 도구와, 도구가 못 보는 실수를 찾아내는 사람의 분석을 함께 씁니다.

테스트는 OWASP와 NIST처럼 세계적으로 인정받는 방법을 따르기 때문에 기분이나 운에 좌우되지 않습니다. 그리고 안전합니다. 데이터를 지우거나 업무를 멈추지 않습니다. 목적은 취약점이 있다는 것을 증명하는 것이지, 그것을 써서 피해를 주는 것이 아니기 때문입니다.

마지막에 무엇을 받고, 언제 다시 테스트할까요?

마지막에는 찾아낸 모든 취약점을 쉬운 말로 정리한 목록을 받으십니다. 취약점마다 무슨 일이 생길 수 있는지, 얼마나 심각한지, 어떻게 고치는지 간단한 설명이 붙어 있습니다. 수정이 끝나면 다시 테스트해서 각 취약점이 서류상으로만이 아니라 실제로 막혔는지 확인합니다.

테스트 한 번으로 평생 안심할 수는 없습니다. 새 결제 수단이나 새 모바일 앱처럼 시스템에 큰 기능을 더할 때마다 없던 문이 새로 열릴 수 있습니다. 그래서 큰 변경이 있을 때마다, 그리고 아무것도 바뀌지 않았더라도 정기적으로 테스트를 반복하시길 권합니다. 프로그램에서는 새로운 취약점이 계속 발견되기 때문입니다.

보호는 출시일 이후에도 계속됩니다

많은 시스템이 잘 만들어진 뒤 그대로 방치됩니다. 몇 달이 지나면 프로그램에 새 취약점이 생기고, 직원이 바뀌고, 검토 없이 서둘러 기능이 더해집니다. 출시일에 안전했던 시스템이 저절로 계속 안전하지는 않습니다.

그래서 저희는 보호를 전용 도구와 담당자가 있는 계속되는 일로 다룹니다. 이어지는 내용에서 매일, 매주 무엇을 해야 하는지, 그리고 실제로 사고가 났을 때 무엇을 해야 하는지 설명합니다.

꾸준한 점검과 24시간 모니터링

꾸준한 점검이란 도구가 정기적으로 시스템을 살펴 알려진 취약점을 찾고, 발견하면 팀에 알리는 것입니다. 길에서 차가 고장 나기를 기다리지 않고 정기 점검을 받는 것과 같습니다. 점검은 오래된 프로그램과 잘못된 설정을 다른 사람보다 먼저 찾아냅니다.

모니터링은 밤낮으로 뜨고 있는 눈입니다. 누군가 몇 분 안에 수백 번 로그인을 시도하거나, 관리자 계정이 한밤중에 낯선 나라에서 로그인하면 바로 알림이 옵니다. 해킹을 한 시간 만에 알아채느냐, 몇 주 뒤에 알아채느냐가 작은 문제와 큰 사고를 가릅니다.

앱 앞을 지키는 방패

웹 방화벽(WAF)은 인터넷과 앱 사이에 서 있는 방패입니다. 웹사이트로 오는 모든 요청은 먼저 이곳을 지나며, 정상 요청은 통과시키고 악성 요청은 막습니다. 예를 들어 입력 양식에 명령어를 써 넣으려는 시도나, 비밀번호를 시험하는 봇을 막습니다.

이 방패는 요청 폭주에 맞서는 데도 도움이 됩니다. 할인 행사 날 진짜 고객이 몰리는 것과 웹사이트를 멈추려는 공격을 구별합니다. 앱 안의 취약점을 고치는 일을 대신하지는 못하지만, 시간을 벌어 주고 자동 공격 대부분이 아예 앱까지 오지 못하게 합니다.

사고가 났을 때를 위한 준비된 계획

보호가 아무리 좋아도, 무슨 일이 생겼을 때 어떻게 할지는 알고 있어야 합니다. 계획이 없는 회사는 처음 몇 시간을 혼란과 전화 속에서 잃어버립니다. 준비된 회사는 모두가 아는 분명한 순서대로 움직입니다.

  1. 차단: 피해를 입은 부분을 떼어 내서 시스템의 나머지로 번지지 않게 합니다.
  2. 조사: 해커가 어떻게, 언제 들어왔고 무엇을 건드렸는지 알아냅니다.
  3. 정리: 해커가 남긴 흔적을 모두 지우고, 문제없는 사본에서 데이터를 되살립니다.
  4. 취약점 막기: 해커가 들어온 문을 고쳐서 같은 길로 다시 들어오지 못하게 합니다.

직원이 첫 번째 방어선입니다

가장 잘 통하는 공격은 프로그램의 취약점이 아니라 메시지 한 통에서 시작됩니다. 직원에게 은행이나 상사가 보낸 것처럼 보이는 이메일이 와서, 링크를 눌러 비밀번호를 입력하라고 합니다. 이것을 피싱이라고 하며, 직원 한 명만 속아도 아무리 좋은 시스템이라도 뚫립니다.

보안 인식 교육은 직원들에게 가짜 메시지를 알아보는 법을 가르치고, 상대가 무슨 말을 하든 로그인 코드를 누구에게도 주지 말라고 가르칩니다. 실수를 부끄러워하지 말고 의심스러운 메시지는 바로 알리라고도 가르칩니다. 몇 시간의 교육이 사업이 겪을 수 있는 가장 위험한 공격을 막을 수 있습니다.

보호 작업의 양과 비용은 무엇으로 정해질까요?

모든 회사에 맞는 단 하나의 견적은 없습니다. 시스템마다 작업량이 다르기 때문입니다. 5페이지짜리 회사 소개 사이트는 결제 기능과 수천 명의 사용자가 있는 플랫폼보다 훨씬 적은 작업이 필요합니다. 무엇이 작업을 늘리고 줄이는지 알면, 받은 견적을 이해하기 쉬워집니다.

기본 원칙은 이렇습니다. 시스템의 문이 많고 안에 든 것이 민감할수록, 지키는 데 더 많은 작업이 필요합니다. 아래 항목은 제대로 된 팀이라면 작업 규모를 짐작하기 전에 꼭 살피는 것들입니다.

앱의 규모와 데이터의 민감도

페이지 수, 사용자 유형, 앱과 연결된 시스템의 수는 모두 점검 범위를 넓힙니다. 고객용 포털, 직원용 포털, 모바일 앱이 있고 결제 수단과도 연결된 시스템이라면 이 모든 부분을 점검해야 합니다. 직원 몇 명이 쓰는 로그인 페이지 하나뿐인 시스템은 훨씬 간단합니다.

데이터의 민감도는 상황을 바꿉니다. 환자 기록, 학생 성적, 결제 정보에는 더 엄격한 암호화와 더 넓은 감사 로그, 때로는 법 준수를 위한 서류가 필요합니다. Acad 학습 관리 시스템 같은 교육 플랫폼은 학생 데이터를 다루므로, 음식 메뉴만 보여 주는 사이트보다 더 많은 관심이 필요합니다.

새 앱인가요, 다른 팀이 만든 기존 앱인가요?

새 앱은 보호하기가 더 쉽습니다. 계획 안에서 처음부터 보호 단계를 함께 만들 수 있기 때문입니다. 기존 앱, 특히 만든 팀이 더 이상 없는 앱은 먼저 안을 이해해야 합니다. 코드에 설명서가 없거나, 프로그램이 오래되었거나, 권한이 뒤섞여 있을 수 있습니다.

이런 경우 저희는 실제 상태를 보여 주는 점검부터 시작하고, 위험도에 따라 수정 순서를 정합니다. 데이터 유출이나 업무 중단으로 이어질 수 있는 부분을 먼저 막고, 그다음 위험이 덜한 부분으로 단계별로 넘어갑니다. 이렇게 하면 업무가 멈추지 않고, 심각한 문제보다 사소한 일에 먼저 힘을 쏟지 않게 됩니다.

계약 전에 어떤 업체에든 물어볼 질문

좋은 제안은 분명한 질문에 답하고, 약한 제안은 피합니다. 어떤 보안 서비스든 동의하기 전에 다음 질문에 서면으로 답해 달라고 하세요.

  • 점검 범위는 정확히 어디까지인가요? 웹사이트만인가요, 앱과 모바일, 연결 부분까지인가요?
  • 알기 쉬운 말로 쓰고, 취약점마다 고치는 방법을 담은 보고서를 받을 수 있나요?
  • 수정 후 재테스트는 계약에 포함되나요, 따로인가요?
  • 밤과 휴일에는 누가 시스템을 지켜보고, 알림에 얼마나 빨리 대응하나요?
  • 사고가 나면 처음 몇 시간 동안 무엇을 하고, 누가 누구에게 연락하나요?
  • 거래를 끝내도 코드와 데이터는 온전히 제 것으로 남나요?

사업주들이 앱 보호에 대해 자주 묻는 질문

매장 사장님, 병원과 학교 관리자분들께 자주 듣는 질문을 모았습니다. 기술 지식 없이도 결정하실 수 있도록 짧고 바로 답했습니다.

찾는 질문이 없다면, 글 아래 질문 목록과 저희 웹사이트의 고객센터에서 다른 질문을 보실 수 있습니다.

좋은 호스팅만으로 앱을 지킬 수 있나요?

좋은 호스팅은 앱이 돌아가는 서버를 지켜 줍니다. 중요한 부분이지만 전부는 아닙니다. 명령어를 받아 주는 입력 양식이나 너무 열린 권한처럼 앱 자체에 취약점이 있다면, 가장 좋은 서버도 해커가 그것을 이용하는 것을 막지 못합니다. 진짜 보호는 보호된 서버와 안전하게 만든 앱을 함께 갖추는 것입니다. 치안이 좋은 동네의 집이라도 내 집 문은 내가 잠가야 하는 것과 같습니다.

내 앱이 해킹당했는지 어떻게 알 수 있나요?

분명한 신호도 있습니다. 페이지 내용이 바뀌거나, 아무도 모르는 계정이 생기거나, 고객이 내 이름으로 이상한 메시지가 왔다고 항의하는 경우입니다. 잘 안 보이는 신호도 있습니다. 이유 없이 느려지거나, 방문자가 다른 사이트로 넘어가는 경우입니다. 문제는 많은 해킹이 몇 주 동안 아무 신호 없이 조용히 이어진다는 점입니다. 그래서 일찍 알아차리는 길은 꾸준한 모니터링과 감사 로그뿐입니다.

모의 해킹 중에 업무가 멈추나요?

아니요, 대부분의 경우 아무것도 멈추지 않습니다. 전문가는 어느 부분을 언제 테스트할지 미리 사장님과 정하고, 업무에 영향을 주거나 데이터를 지울 수 있는 행동은 피합니다. 민감한 시스템이라면 고객이 쓰는 실제 시스템이 아니라 똑같이 만든 복사본에서 테스트할 수 있습니다. 이렇게 하면 고객은 아무것도 모른 채 결과만 받아 보실 수 있습니다.

이미 운영 중인 앱을 안전하게 만드는 데 얼마나 걸리나요?

앱의 규모와 상태에 따라 다릅니다. 작은 앱의 첫 점검은 며칠이면 끝날 수 있지만, 부분이 많은 큰 플랫폼은 몇 주가 필요합니다. 점검 뒤에는 심각도 순서대로 수정이 이어집니다. 심각한 취약점은 대개 가장 먼저, 며칠 안에 막고, 나머지는 단계별로 처리합니다.

회사 안에 보안팀이 꼭 있어야 하나요?

대부분의 중소기업은 회사 안에 완전한 팀을 둘 필요가 없습니다. 보통은 회사 안의 담당자 한 명과, 점검·모니터링·대응을 맡는 전문 외부 파트너면 충분합니다. 중요한 것은 책임을 글로 분명히 나눠서, 서로 상대가 맡고 있다고 착각하지 않게 하는 것입니다. 시스템이 크고 데이터가 민감할수록 더 가까이에서 챙겨야 합니다.

이번 주에 이 세 가지부터 시작하세요

시작하는 데 거창한 계획은 필요 없습니다. 첫째, 사업이 인터넷에 가진 모든 것, 곧 웹사이트, 쇼핑몰, 예약 시스템, 모바일 앱과 각각에 누가 로그인할 수 있는지 목록을 만드세요. 둘째, 모든 관리자 계정에 여러 단계 로그인을 켜고, 퇴사한 직원의 계정을 지우세요. 셋째, 시스템을 관리하는 분께 한 가지만 물어보세요. 마지막으로 실제로 백업 복원을 해 본 게 언제인가요?

그다음은 전문 점검입니다. Linkysoft에서는 무료 보안 점검과 상담을 제공합니다. 저희가 만든 시스템이든 다른 팀이 만든 시스템이든, 앱을 살펴보고 가장 심각한 약점과 먼저 고쳐야 할 부분을 분명하게 알려 드립니다. 문의 페이지에서 신청하실 수 있고, 결정하기 전에 더 읽어 보고 싶으시면 고객센터에서 실용적인 답을 찾으실 수 있습니다.

같은 주제의 유용한 글들을 더 읽어보세요.