정보보안 이해와 활용

1. 보안의 세 목표 — 기밀성·무결성·가용성을 지킨다

정보보안은 자료와 시스템을 허가받지 않은 열람·변경·중단으로부터 보호하는 일입니다. 세 가지 목표를 구분하면 어떤 피해를 막으려는지 설명하기 쉽습니다.

기밀성은 허가받지 않은 사람이 내용을 보지 못하게 하는 것입니다. 무결성은 자료가 부적절하게 바뀌거나 지워지지 않고 정확하고 온전하게 유지되게 하는 것입니다. 가용성은 허가받은 사람이 필요할 때 자료와 기능을 사용할 수 있게 하는 것입니다.

성적 시스템을 예로 들면 다른 학생의 성적을 몰래 보는 일은 기밀성, 점수를 함부로 바꾸는 일은 무결성, 성적 확인 기간에 시스템이 멈추는 일은 가용성과 관련됩니다. 하나의 사고가 여러 목표에 영향을 줄 수도 있습니다. 보호할 대상마다 누가 어떤 피해를 입는지 생각해 대책을 고릅니다.

생각해 볼 질문
무엇이 노출·변조·중단되면 누구에게 어떤 피해가 생깁니까?

2. 최소 권한 — 필요한 일만 할 수 있게 한다

최소 권한은 맡은 일을 하는 데 필요한 자료와 기능만 사용할 수 있게 하는 원칙입니다. 권한은 단순히 ‘접속 가능’ 하나가 아닙니다. 어떤 자료를 볼 수 있는지, 수정·삭제·다운로드도 가능한지, 언제까지 사용할 수 있는지를 나눠 정합니다.

예를 들어 배송 담당자는 배송할 주소를 볼 필요가 있지만 전체 고객 자료를 삭제할 필요는 없습니다. 필요 없는 삭제 권한을 주지 않으면 실수나 계정 도용이 발생해도 피해 범위를 줄일 수 있습니다. 업무가 바뀌거나 끝나면 예전 권한도 다시 확인하고 회수합니다.

생각해 볼 질문
이 사람이 이 자료와 기능에 계속 접근해야 할 업무상 이유가 있습니까?

3. 인증과 인가 — 본인 확인과 허용 범위를 구분한다

식별은 ‘나는 이 계정의 사용자입니다’라고 신원을 밝히는 것이고, 인증은 그 주장이 맞는지 확인하는 것입니다. 로그인 화면에 아이디를 적고 비밀번호로 본인임을 확인받는 상황을 떠올릴 수 있습니다. 인가는 확인된 사용자가 어떤 자료에 어떤 행동을 해도 되는지 판단하는 것입니다.

쇼핑몰에 로그인했다고 다른 고객의 주문을 볼 권한까지 생기지는 않습니다. 그래서 서버는 주문 조회 요청마다 그 주문의 주인이 누구인지와 조회 권한을 확인해야 합니다. 화면에서 버튼만 숨겨도 다른 방법으로 요청을 보낼 수 있으므로 실제 자료를 보내는 서버에서 검사해야 합니다.

생각해 볼 질문
서버가 로그인 여부뿐 아니라 요청한 주문의 소유자와 허용된 역할까지 확인하나요?

4. 시큐어 코딩 — 외부 입력과 명령을 분리한다

시큐어 코딩은 프로그램을 만들면서 공격에 이용될 수 있는 약점을 줄이는 활동입니다. 외부에서 받은 값은 개발자가 기대한 모양으로만 들어온다고 믿을 수 없습니다. 수량 입력칸에 음수가 들어오거나 화면의 제한을 거치지 않은 요청이 올 수도 있습니다.

SQL은 데이터베이스에 조회·수정 등을 요청하는 명령입니다. 사용자의 입력을 SQL 문장에 그대로 이어 붙이면 입력이 값이 아니라 명령의 일부로 해석될 수 있습니다. 매개변수 질의는 명령의 구조를 먼저 정하고 입력값을 별도로 전달해 이 문제를 막습니다. 수량의 허용 범위 검사와 명령·값의 분리는 목적이 다르므로 둘 다 확인합니다.

생각해 볼 질문
음수나 지나치게 큰 주문 수량을 서버에서 거절하나요? 입력값이 데이터베이스 명령으로 실행되지 않게 처리했나요?

5. 비밀과 민감정보 — 접근 키와 암호화 키의 노출을 줄인다

암호화 키는 데이터를 암호화하거나 원래 내용으로 복원할 때 사용하는 값입니다. 외부 서비스 접근 키는 그 서비스를 사용할 권한을 증명하는 값입니다. 용도는 다르지만 둘 다 허가받지 않은 사람에게 공개되면 안 되는 비밀입니다.

이런 값을 코드에 직접 적으면 코드를 공유하거나 복사할 때 함께 퍼질 수 있습니다. 필요한 프로그램과 담당자만 별도로 받아 사용하게 하고 접근을 제한해야 합니다. 이미 노출된 접근 키는 파일에서 지워도 누군가 복사했을 수 있으므로 기존 키를 사용 중지하고 새 키로 바꿉니다. 암호화 키를 교체할 때는 기존 데이터를 계속 복원할 방법도 고려해야 합니다.

생각해 볼 질문
접근 키가 소스 코드·로그·복사본에 남아 있나요? 노출됐을 때 기존 키를 중지하고 새 키로 교체할 수 있나요?

6. CVE와 취약점 대응 — 사용 중인 구성 요소를 확인한다

취약점은 공격자가 악용할 수 있는 보안상의 약점입니다. CVE는 알려진 취약점을 구분하는 식별 번호이고, CVSS는 취약점의 심각도를 평가하는 점수 체계입니다. 번호는 ‘어느 문제인가’, 점수는 ‘어느 정도로 심각한가’를 파악하는 데 쓰입니다.

공지에서 높은 점수를 봤더라도 우리 서비스가 해당 제품과 버전을 사용하는지부터 확인해야 합니다. 같은 제품을 써도 문제가 있는 기능을 외부에서 이용할 수 있는지에 따라 실제 위험이 달라질 수 있습니다. 사용 중인 제품·버전·담당자를 기록하고, 노출 범위와 업무 영향을 함께 보며 수정 순서를 정합니다.

생각해 볼 질문
문제가 알려진 구성 요소를 어디서 사용하는지와 수정 담당자를 찾을 수 있습니까?

7. 다층 방어 — 하나가 실패해도 피해를 제한한다

다층 방어는 한 가지 보호 방법이 실패해도 다른 보호 방법이 피해를 줄이도록 여러 조치를 함께 두는 것입니다. 방화벽을 설치했으니 모든 위험이 사라졌다고 생각하지 않고, 계정 권한·자료 접근 범위·기록과 경보도 함께 준비합니다.

예를 들어 웹 서버 계정은 주문을 저장할 수 있지만 백업을 삭제할 수는 없게 정합니다. 그 계정을 빼앗겨도 복구용 사본까지 지워지는 일을 줄이려는 것입니다. 여러 제품을 샀는지보다 각 조치가 어떤 실패를 막으며 함께 무너질 조건은 없는지 확인해야 합니다.

생각해 볼 질문
웹 서버 계정을 빼앗겨도 백업을 삭제할 수 없게 막았나요? 추가 침입을 발견할 기록과 경보도 있나요?

8. ISMS와 사고 대응 — 이상을 확인하고 대응할 담당자와 절차를 정한다

ISMS는 정보보호 관리체계입니다. 조직이 가진 자료와 시스템에서 어떤 사고가 날 수 있는지 살피고, 대책을 실행한 뒤 실제로 작동하는지 점검하며 고치는 활동을 말합니다. 보안 정책 문서를 한 번 만드는 것으로 끝나지 않습니다.

자료가 평소보다 많이 내려받아졌다는 경보를 예로 들어 봅시다. 정상적인 작업인지 누가 확인하고, 의심스러우면 누가 접근을 제한할지 정해 둬야 합니다. 담당자가 없는 경보는 울려도 대응으로 이어지지 않습니다. 조사에 필요한 기록을 보존하고 원인과 대응 결과를 다음 개선에 반영합니다.

생각해 볼 질문
경보가 울린 뒤 누가 무엇을 확인하고 어떤 결정을 내립니까?

9. 복구와 업무 연속성 — 사고 뒤에도 필요한 일을 한다

업무 연속성은 장애나 사고가 나도 중요한 일을 이어 갈 수 있도록 준비하는 것입니다. 재난복구는 손상되거나 멈춘 시스템을 복원하는 일입니다. 시스템을 복구하는 동안 사람들은 어떤 방법으로 일할지도 함께 정해야 합니다.

주문 시스템이 멈췄을 때 임시 접수표로 주문을 받는다면 누가 번호를 부여하고 보관할지 정합니다. 복구 뒤에는 임시 주문을 옮기면서 누락과 중복을 확인합니다. 백업은 실제로 복원할 수 있어야 하고, 운영 계정을 빼앗긴 공격자가 백업도 쉽게 훼손하지 못하게 보호해야 합니다.

생각해 볼 질문
시스템이 멈춘 동안 주문을 어떻게 접수하나요? 복구한 뒤 임시 주문이 빠지거나 중복되지 않았는지 확인하나요?

10. 사람이 지킬 수 있는 절차 — 안전한 행동을 쉽게 만든다

사람이 실제 업무에서 지킬 수 있어야 보안 절차가 효과를 냅니다. 규칙을 반복해서 어긴다면 개인의 부주의뿐 아니라 규칙대로 일하기 어려운 이유도 살펴야 합니다.

예를 들어 공식 파일 공유 승인이 며칠씩 걸리는데 당일 제출을 요구하면 직원은 개인 공유 서비스를 쓰려 할 수 있습니다. 금지 공지만 추가하기보다 승인된 공유 방법으로 필요한 시간 안에 전달할 수 있도록 절차를 개선해야 합니다. 실수로 잘못 보냈을 때 바로 알릴 통로도 마련하면 피해를 더 빨리 줄일 수 있습니다.

생각해 볼 질문
직원이 공식 공유 절차로 필요한 시간 안에 파일을 전달할 수 있나요? 실수로 잘못 공유했을 때 신고할 곳을 알고 있나요?

11. 자산 목록 — 보호할 시스템과 담당자를 빠짐없이 기록한다

정보자산은 보호할 가치가 있는 자료·서버·프로그램·계정 등을 말합니다. 무엇이 있는지 모르면 어느 서버에 업데이트가 필요하고 누가 처리해야 하는지 알기 어렵습니다. 그래서 자산 목록에는 이름뿐 아니라 용도·담당자·외부 공개 여부·사용 종료 시점도 적습니다.

행사용 시험 서버를 행사가 끝난 뒤에도 켜 두었다고 합시다. 담당자가 바뀌면 업데이트와 계정 관리에서 빠질 수 있습니다. 목록을 실제 실행 중인 시스템과 비교하고, 쓰지 않는 서버는 계속 둘 이유가 있는지 확인해야 합니다.

생각해 볼 질문
운영 중인 서버·서비스·계정마다 담당자와 사용 목적이 있나요? 사용이 끝났는데 남아 있는 자산은 없나요?

12. Secure SDLC와 위협 분석 — 기능을 악용할 방법과 피해를 미리 살핀다

위협 분석은 기능이 정상적으로 쓰이는 상황뿐 아니라 잘못 사용되거나 공격받는 상황을 미리 생각하는 일입니다. 누가 어떤 자료를 보내고, 어디에 저장되며, 누가 읽을 수 있는지 따라가면서 피해가 생길 지점을 찾습니다.

파일 업로드라면 큰 파일로 저장공간을 채우는 경우, 다른 사람의 비공개 파일을 읽는 경우, 실행하면 위험한 파일을 올리는 경우를 생각할 수 있습니다. 그 결과를 크기 제한·저장 위치·조회 권한과 시험 항목에 반영합니다. 보안을 개발 전 과정에 넣는 Secure SDLC에서는 이런 검토를 요구사항과 설계 단계부터 시작합니다.

생각해 볼 질문
이 기능을 원래 의도와 다르게 사용하면 어떤 피해가 생길 수 있습니까?

13. 계정 수명주기 — 생성부터 회수까지 관리한다

계정의 수명주기는 계정을 만들고, 사용하는 동안 권한을 바꾸고, 필요가 끝나면 접근을 회수하는 전체 과정입니다. 처음에 알맞은 권한을 줬더라도 맡은 역할이 바뀌면 그대로 두어서는 안 됩니다.

매장의 정산 담당자가 다른 지점으로 옮겼는데 이전 지점의 지급 계좌를 계속 수정할 수 있다고 생각해 봅시다. 새 담당자의 권한을 주는 일과 전임자의 불필요한 권한을 거두는 일을 함께 해야 합니다. 회사에서는 부서 이동·퇴사·외주 계약 종료와 계정 관리를 연결하고 처리 여부를 확인합니다.

생각해 볼 질문
역할이 끝난 사람의 접근을 언제 어떻게 회수합니까?

14. 다중 인증과 복구 — 인증 수단 재등록 때도 본인을 확인한다

다중 요소 인증은 서로 다른 종류의 증거를 함께 확인해 본인인지 판단하는 방법입니다. 비밀번호처럼 아는 것, 인증 기기처럼 가진 것, 지문처럼 본인에게 속한 특징을 구분합니다. 비밀번호와 다른 비밀번호를 두 번 묻는다고 서로 다른 요소가 되는 것은 아닙니다.

로그인은 엄격해도 ‘휴대전화를 잃어버렸다’는 말만 듣고 인증 기기를 바꿔 주면 다른 사람이 계정을 차지할 수 있습니다. 새 인증 수단을 등록하는 과정에서도 본인을 확인하고, 변경 사실을 사용자에게 알릴 방법을 준비해야 합니다.

생각해 볼 질문
다른 사람이 휴대전화를 잃어버렸다고 주장하면 인증 수단을 바꿀 수 있나요? 재등록 때 본인 확인을 충분히 하나요?

15. 안전한 기본값 — 처음부터 노출을 줄인다

기본값은 사용자가 설정을 바꾸지 않았을 때 적용되는 상태입니다. 안전한 기본값은 처음부터 필요한 범위만 허용하고 더 넓은 공개는 사용자가 확인해서 선택하게 만드는 것입니다.

문서를 올리자마자 누구나 볼 수 있다면 작성자가 설정을 확인하기 전에 자료가 퍼질 수 있습니다. 처음에는 허가한 사람만 볼 수 있게 하고, 공개할 때 대상과 의미를 보여 주면 실수 가능성을 줄일 수 있습니다. 화면에 ‘비공개’라고 적혀 있어도 실제 파일 주소로 접근할 수 있다면 보호된 상태가 아니므로 실제 접근도 확인합니다.

생각해 볼 질문
문서를 처음 올렸을 때 허가한 사람만 볼 수 있나요? 작성자가 공개 범위를 확인한 뒤 넓히도록 되어 있나요?

16. 보안 기록 — 증거를 남기되 비밀을 복사하지 않는다

보안 기록은 누가 언제 어떤 자료에 접근하고 권한을 바꿨는지 나중에 확인할 근거입니다. 로그인 실패나 자료 다운로드의 시각·대상·결과를 남기면 이상한 행동을 조사하는 데 도움이 됩니다.

그러나 요청 내용을 통째로 기록하면 비밀번호나 인증 키도 복사될 수 있습니다. 조사에 필요한 항목을 정해 남기고, 기록을 볼 수 있는 사람도 제한해야 합니다. 기록의 목적과 보관 기준을 정하되 구판 교재에 나온 기간을 그대로 현재 의무라고 사용하지 않습니다.

생각해 볼 질문
오류 분석에 필요한 요청 시각과 결과는 남기나요? 비밀번호나 인증 키가 로그에 함께 저장되지는 않나요?

17. 전자서명과 공급망 신뢰 — 받은 배포물을 확인한다

전자서명은 개인키로 서명하고 짝이 되는 공개키로 확인하는 기술입니다. 신뢰할 수 있는 공개키를 기준으로 서명한 주체와 서명 이후 내용이 바뀌었는지를 확인하는 데 사용합니다.

설치 파일을 받을 때는 어디에서 받았는지, 예상한 배포자의 서명이 맞는지도 확인합니다. 이름이 비슷한 다른 프로그램을 받지 않았는지와 버전도 살펴야 합니다. 유효한 서명은 그 프로그램에 버그나 악성 기능이 전혀 없다는 보증은 아니므로, 승인된 경로와 변경 검토를 함께 사용합니다.

생각해 볼 질문
전자서명 검증으로 확인할 수 있는 것은 무엇이며, 서명이 맞아도 따로 검토해야 할 것은 무엇입니까?

18. 업무상 사칭 — 급한 요청도 확인 절차를 지킨다

스피어 피싱은 특정 사람이나 직무를 노려 신뢰할 만한 요청처럼 속이는 공격입니다. 공격자는 이름·역할·거래 관계 등을 알아내 실제 담당자의 부탁처럼 보이는 메시지를 보낼 수 있습니다.

예를 들어 거래처를 사칭한 메일이 ‘오늘부터 새 계좌로 보내 달라’고 요구할 수 있습니다. 메일에 적힌 새 번호로만 확인하면 공격자에게 다시 묻게 될 수 있습니다. 원래 알고 있던 연락 경로로 요청이 맞는지 확인하고 중요한 변경의 검토 절차를 지켜야 합니다.

생각해 볼 질문
긴급 메시지에 적힌 번호 대신 원래 알고 있던 연락처로 요청자를 확인하나요?

19. 자료 폐기 — 사용이 끝난 복사본까지 살핀다

자료를 더 이상 쓰지 않아도 내려받은 파일이나 시험용 복사본이 남아 있으면 정보가 노출될 수 있습니다. 자료 폐기에서는 원본뿐 아니라 어디에 사본이 있는지도 확인해야 합니다.

고객 자료를 분석한 뒤 결과만 남기고 원본 사본은 정리하기로 했다면, 공유 폴더와 개인 작업 폴더도 처리 대상에 포함합니다. 다만 업무가 끝났다는 이유로 모든 자료를 임의로 지우는 것은 아닙니다. 보존해야 할 자료와 삭제할 자료를 담당자가 구분하고, 매체에 맞는 방법으로 처리한 결과를 확인합니다.

생각해 볼 질문
업무 종료 후 원본·다운로드 파일·시험용 사본을 누가 처리하나요? 보존해야 할 자료와 삭제할 자료를 구분했나요?

20. Secure SDLC — 보안 검증을 개발 전 과정에 넣는다

Secure SDLC는 소프트웨어를 만드는 전체 과정에 보안 활동을 포함하는 방식입니다. SDLC는 요구사항 정의·설계·구현·시험·운영으로 이어지는 개발 생명주기를 뜻합니다.

회원 문서를 저장하는 기능이라면 요구사항에서 ‘누가 읽을 수 있는가’를 정하고, 설계에서는 요청마다 권한을 확인할 위치를 정합니다. 구현 후에는 허용된 요청과 거부할 요청을 모두 시험하며, 운영 중 변경할 때도 권한 검사에 영향이 있는지 확인합니다. 공개 직전에 검사 도구를 한 번 실행하는 것만으로 이 과정을 대신할 수는 없습니다.

생각해 볼 질문
권한 없는 요청은 실제로 차단되나요? 침입 탐지와 복구도 승인된 시험 환경에서 확인했나요?