Blog·인사이트

보안, 나중에 하면 안 되는 이유

··4분 읽기

"보안은 서비스가 커지면 그때 하면 되죠."

이 말을 듣기 전에 먼저 이야기하겠습니다. 보안 사고는 서비스가 클 때만 일어나지 않습니다. 오히려 보안에 신경 쓰지 않는 작은 서비스가 더 쉬운 타겟입니다. 해커 입장에서 보안이 허술한 곳을 뚫는 것이 당연히 효율적이니까요.

개인정보 유출 시 법적 책임

개인정보보호법에 따라, 개인정보가 유출되면 서비스 운영자(사업자)가 책임을 집니다.

  • 과태료: 위반 사항에 따라 수천만 원
  • 손해배상: 유출된 이용자에게 배상 의무
  • 형사처벌: 중대한 과실이면 대표자 형사 책임 가능
  • 이미지 손실: 기사화되면 서비스 신뢰도 회복 불가

"개발사가 보안 처리를 안 해줬어요"는 면책이 되지 않습니다. 보안은 개발사의 의무이기도 하지만, 최종 책임은 서비스 운영자에게 있습니다.

"일단 만들고 보안은 나중에"의 문제

보안을 나중에 추가하는 것은 집을 다 지은 뒤에 기초를 보강하는 것과 같습니다.

구조적으로 안 되는 경우

비밀번호를 평문(암호화 없이)으로 저장한 DB를 나중에 암호화로 전환하려면? 기존 사용자 전원의 비밀번호를 리셋해야 합니다. 또는 복잡한 마이그레이션 로직을 만들어야 합니다.

API에 인증 없이 접근할 수 있는 구조로 만들어놓고, 나중에 인증을 추가하려면? 모든 API에 인증 로직을 넣고, 프론트엔드에서 토큰 관리를 추가하고, 기존 사용자 세션을 처리해야 합니다. 사실상 재설계입니다.

이미 유출된 후에는 늦다

보안 사고의 특성상, 발생하기 전에는 비용이 보이지 않습니다. "아직 아무 일 없잖아"라고 생각하다가, 한 번 터지면 수습 비용이 보안 투자 비용의 수십 배입니다.

기본적인 보안 체크리스트

보안 전문가 수준의 작업이 아니어도, 아래 항목은 모든 서비스에서 기본으로 적용해야 합니다.

HTTPS 적용

HTTP로 서비스를 운영하면, 사용자의 로그인 정보, 개인정보가 네트워크에서 평문으로 전송됩니다. 누구나 볼 수 있다는 뜻입니다. HTTPS는 선택이 아니라 필수입니다. Let's Encrypt로 무료 SSL 인증서를 발급받을 수 있으니, 비용 문제도 아닙니다.

비밀번호 암호화

비밀번호를 DB에 평문으로 저장하는 서비스가 아직도 있습니다. bcrypt, argon2 같은 해싱 알고리즘을 사용해야 합니다. 단방향 해싱이므로 원본 비밀번호를 복원할 수 없어야 합니다.

비밀번호를 MD5나 SHA-1으로 해싱하는 것도 충분하지 않습니다. 이 알고리즘은 보안 용도로는 더 이상 안전하지 않습니다.

SQL 인젝션 방어

사용자 입력값이 DB 쿼리에 직접 들어가면, 공격자가 쿼리를 조작할 수 있습니다. 로그인을 우회하거나, DB 전체 데이터를 추출하거나, 데이터를 삭제하는 것이 가능합니다.

ORM(Django, TypeORM 등)을 사용하면 기본적으로 방어되지만, 직접 SQL을 작성하는 경우 파라미터 바인딩을 반드시 사용해야 합니다.

XSS(크로스 사이트 스크립팅) 방어

게시판, 댓글, 프로필 등 사용자가 텍스트를 입력하는 곳에서, 악성 스크립트를 삽입할 수 있습니다. 다른 사용자가 해당 페이지를 열면 스크립트가 실행되어 쿠키 탈취, 세션 하이재킹이 가능합니다.

입력값을 화면에 표시할 때 HTML 이스케이프 처리를 해야 합니다. React 같은 프레임워크는 기본적으로 이스케이프를 하지만, dangerouslySetInnerHTML 같은 예외를 사용할 때 주의가 필요합니다.

인증과 인가

  • 인증(Authentication): 이 사용자가 누구인지 확인 (로그인)
  • 인가(Authorization): 이 사용자가 이 행동을 할 수 있는지 확인 (권한)

모든 API에 인증을 적용하고, 인가를 확인해야 합니다. "로그인한 사용자"라고 해서 모든 데이터에 접근할 수 있으면 안 됩니다. 내 주문만 볼 수 있어야 하고, 다른 사람의 주문을 URL 조작으로 볼 수 없어야 합니다.

민감 정보 관리

  • DB 비밀번호, API 키를 소스코드에 직접 쓰지 않는다 (환경 변수 사용)
  • .env 파일을 Git에 올리지 않는다 (.gitignore 설정)
  • 에러 메시지에 서버 내부 정보가 노출되지 않게 한다

보안은 기능이 아니라 기반이다

보안은 "나중에 추가하는 기능"이 아닙니다. 개발을 시작할 때부터 설계에 포함되어야 하는 기반입니다.

HTTPS는 서버 세팅 단계에서. 비밀번호 암호화는 회원 기능 개발할 때. 인증/인가는 API를 만들 때. SQL 인젝션과 XSS 방어는 코드를 작성할 때. 처음부터 하면 추가 비용이 거의 들지 않습니다. 나중에 하면 구조를 뜯어고쳐야 합니다.

개발 견적을 받을 때, "보안은 어떻게 처리하나요?"라고 물어보세요. 명확하게 답변하는 개발사가 신뢰할 수 있는 개발사입니다.

*보안을 고려한 서비스 개발이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 처음부터 보안이 설계된 서비스를 만들어 드립니다.*


보안,개인정보,HTTPS,SQL인젝션
다른 포스팅
Blog·인사이트

보안, 나중에 하면 안 되는 이유

··4분 읽기

"보안은 서비스가 커지면 그때 하면 되죠."

이 말을 듣기 전에 먼저 이야기하겠습니다. 보안 사고는 서비스가 클 때만 일어나지 않습니다. 오히려 보안에 신경 쓰지 않는 작은 서비스가 더 쉬운 타겟입니다. 해커 입장에서 보안이 허술한 곳을 뚫는 것이 당연히 효율적이니까요.

개인정보 유출 시 법적 책임

개인정보보호법에 따라, 개인정보가 유출되면 서비스 운영자(사업자)가 책임을 집니다.

  • 과태료: 위반 사항에 따라 수천만 원
  • 손해배상: 유출된 이용자에게 배상 의무
  • 형사처벌: 중대한 과실이면 대표자 형사 책임 가능
  • 이미지 손실: 기사화되면 서비스 신뢰도 회복 불가

"개발사가 보안 처리를 안 해줬어요"는 면책이 되지 않습니다. 보안은 개발사의 의무이기도 하지만, 최종 책임은 서비스 운영자에게 있습니다.

"일단 만들고 보안은 나중에"의 문제

보안을 나중에 추가하는 것은 집을 다 지은 뒤에 기초를 보강하는 것과 같습니다.

구조적으로 안 되는 경우

비밀번호를 평문(암호화 없이)으로 저장한 DB를 나중에 암호화로 전환하려면? 기존 사용자 전원의 비밀번호를 리셋해야 합니다. 또는 복잡한 마이그레이션 로직을 만들어야 합니다.

API에 인증 없이 접근할 수 있는 구조로 만들어놓고, 나중에 인증을 추가하려면? 모든 API에 인증 로직을 넣고, 프론트엔드에서 토큰 관리를 추가하고, 기존 사용자 세션을 처리해야 합니다. 사실상 재설계입니다.

이미 유출된 후에는 늦다

보안 사고의 특성상, 발생하기 전에는 비용이 보이지 않습니다. "아직 아무 일 없잖아"라고 생각하다가, 한 번 터지면 수습 비용이 보안 투자 비용의 수십 배입니다.

기본적인 보안 체크리스트

보안 전문가 수준의 작업이 아니어도, 아래 항목은 모든 서비스에서 기본으로 적용해야 합니다.

HTTPS 적용

HTTP로 서비스를 운영하면, 사용자의 로그인 정보, 개인정보가 네트워크에서 평문으로 전송됩니다. 누구나 볼 수 있다는 뜻입니다. HTTPS는 선택이 아니라 필수입니다. Let's Encrypt로 무료 SSL 인증서를 발급받을 수 있으니, 비용 문제도 아닙니다.

비밀번호 암호화

비밀번호를 DB에 평문으로 저장하는 서비스가 아직도 있습니다. bcrypt, argon2 같은 해싱 알고리즘을 사용해야 합니다. 단방향 해싱이므로 원본 비밀번호를 복원할 수 없어야 합니다.

비밀번호를 MD5나 SHA-1으로 해싱하는 것도 충분하지 않습니다. 이 알고리즘은 보안 용도로는 더 이상 안전하지 않습니다.

SQL 인젝션 방어

사용자 입력값이 DB 쿼리에 직접 들어가면, 공격자가 쿼리를 조작할 수 있습니다. 로그인을 우회하거나, DB 전체 데이터를 추출하거나, 데이터를 삭제하는 것이 가능합니다.

ORM(Django, TypeORM 등)을 사용하면 기본적으로 방어되지만, 직접 SQL을 작성하는 경우 파라미터 바인딩을 반드시 사용해야 합니다.

XSS(크로스 사이트 스크립팅) 방어

게시판, 댓글, 프로필 등 사용자가 텍스트를 입력하는 곳에서, 악성 스크립트를 삽입할 수 있습니다. 다른 사용자가 해당 페이지를 열면 스크립트가 실행되어 쿠키 탈취, 세션 하이재킹이 가능합니다.

입력값을 화면에 표시할 때 HTML 이스케이프 처리를 해야 합니다. React 같은 프레임워크는 기본적으로 이스케이프를 하지만, dangerouslySetInnerHTML 같은 예외를 사용할 때 주의가 필요합니다.

인증과 인가

  • 인증(Authentication): 이 사용자가 누구인지 확인 (로그인)
  • 인가(Authorization): 이 사용자가 이 행동을 할 수 있는지 확인 (권한)

모든 API에 인증을 적용하고, 인가를 확인해야 합니다. "로그인한 사용자"라고 해서 모든 데이터에 접근할 수 있으면 안 됩니다. 내 주문만 볼 수 있어야 하고, 다른 사람의 주문을 URL 조작으로 볼 수 없어야 합니다.

민감 정보 관리

  • DB 비밀번호, API 키를 소스코드에 직접 쓰지 않는다 (환경 변수 사용)
  • .env 파일을 Git에 올리지 않는다 (.gitignore 설정)
  • 에러 메시지에 서버 내부 정보가 노출되지 않게 한다

보안은 기능이 아니라 기반이다

보안은 "나중에 추가하는 기능"이 아닙니다. 개발을 시작할 때부터 설계에 포함되어야 하는 기반입니다.

HTTPS는 서버 세팅 단계에서. 비밀번호 암호화는 회원 기능 개발할 때. 인증/인가는 API를 만들 때. SQL 인젝션과 XSS 방어는 코드를 작성할 때. 처음부터 하면 추가 비용이 거의 들지 않습니다. 나중에 하면 구조를 뜯어고쳐야 합니다.

개발 견적을 받을 때, "보안은 어떻게 처리하나요?"라고 물어보세요. 명확하게 답변하는 개발사가 신뢰할 수 있는 개발사입니다.

*보안을 고려한 서비스 개발이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 처음부터 보안이 설계된 서비스를 만들어 드립니다.*


보안,개인정보,HTTPS,SQL인젝션
다른 포스팅
WebGL프로젝트 상담