잼잼테크

1인 개발자 보안 체크리스트 - 배포 전 55항목을 전자책으로 묶었습니다

AI 코딩 도구로 사이드 프로젝트를 만들다 보면 권한 오류에서 한 번쯤 막힙니다. 이때 AI가 "더 센 키를 쓰면 됩니다"라고 제안하고, 그대로 바꾸면 오류가 깔끔하게 사라지죠. 화면은 잘 돌아가는데, 그 순간 DB가 인터넷에 열려 있을 수 있습니다. 정상 사용자로 테스트하면 모든 기능이 잘 동작하니 아무도 눈치채지 못하고요. 이런 구멍을 배포 전에 직접 찾아 막을 수 있도록, 이 블로그에서 직접 만든 전자책을 냈습니다. 광고 글이라는 점을 먼저 밝혀 두고, 책에 무엇이 들어 있고 누구에게 맞지 않는지까지 솔직하게 적어 볼게요.1인 개발자를 위한 쉬운 보안 설명서는 어떤 책인가제목은 「1인 개발자를 위한 쉬운 보안 설명서: 다들 털리기 전까진 모릅니다」입니다. 혼자 또는 소수로 서비스를 만드는 개발자가 ..

10월 22일 KISA 보호나라에 "PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙"이 올라왔습니다. 로그인 없이 외부에서 서버 명령을 실행할 수 있는 취약점인데, 보안 업데이트 배포 전에 정보가 유출됐고 해외에서 공격 시도가 보고됐다고 합니다. 서버 담당자에게 남는 질문은 둘입니다. 우리 서버의 PHP는 안전한 버전인지, 이미 누가 들어왔다 나간 건 아닌지. 결론부터 말하면 순서는 실제 버전 확인 → 업데이트와 재시작 → 로그 점검 → 인증정보 교체이고, 이 글은 그 순서를 자체 랩에서 실행한 명령으로 따라갑니다.PHP2Shell, 두 개의 CVE가 노리는 지점 (개념)PHP2Shell은 두 취약점을 묶어 부르는 이름입니다. 둘 다 CVSS v4.0 기준 9.2(치명적)이고, 영향 버전..

보안 점검 질의서에 "비밀번호는 암호화하여 저장합니까?"라는 항목이 있으면, 답변란에 "예, SHA-256으로 암호화"라고 적힌 경우를 흔히 봅니다. 반대로 주민등록번호 칸에 "SHA-256 적용"이라고 적어 놓고, 화면에서는 번호를 다시 보여 줘야 해서 담당자가 곤란해지는 경우도 있습니다. 둘 다 해시와 암호화를 같은 것으로 본 데서 생기는 혼란이에요. 「개인정보의 안전성 확보조치 기준」(개인정보보호위원회고시 제2026-9호, 시행 2026. 7. 1.) 제7조제1항 단서도 "비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다."라고 적고 있어서, 해시가 '일방향 암호화'로 불립니다. 여기에 실무에서는 일반 암호화를 흔히 '양방향 암호화'라고 부르니 '암호화'라는 말 하..

일기를 써 보겠다고 노트를 펴면 첫 줄에서 막히는 경우가 많습니다. 오늘 뭘 했는지는 떠오르는데, 그래서 어땠는지는 잘 안 써지거든요. 누가 옆에서 "그때 기분이 어땠어요?" 하고 한 번만 물어봐 주면 술술 나올 텐데요. 그 역할을 대신해 주는 서비스를 직접 만들었습니다. AI가 질문을 건네고 내가 답하는 방식의 일기, 봉오리(https://bongori.app) 입니다. 이번 글에서는 어떻게 쓰는지, 어떤 기능이 있는지, 그리고 보안 일을 하는 사람으로서 가장 신경 쓴 "기록을 어떻게 지키는가"까지 차례로 보여 드릴게요.빈 페이지 대신 질문으로 시작하는 일기봉오리의 핵심은 단순합니다. 내가 먼저 쓰는 게 아니라, 질문에 답하면서 씁니다.질문 하나를 고릅니다. 오늘의 질문이나 '하루 돌아보기', '불안 ..

보안 점검 결과서를 받으면 "개인정보의 안전성 확보조치 기준 제8조 미준수" 같은 문장이 적혀 있습니다. 그런데 정작 개인정보 보호법을 펴 보면 안전조치에 관한 조문은 제29조 한 줄뿐이에요. 접속기록을 몇 년 보관하라는 숫자도, 어떤 정보를 암호화하라는 목록도 법에는 없습니다. 그 숫자들은 법이 시행령에, 시행령이 고시에 넘긴 결과입니다. 이 연결 고리를 한 번 잡아 두면 점검 지적 하나를 받았을 때 "이게 법 위반인가, 권고인가"를 스스로 판단할 수 있게 됩니다.이 글은 2026년 10월 6일 국가법령정보센터에서 확인한 시행 중 조문을 기준으로 합니다.법 제29조에서 고시까지 이어지는 세 단계 (근거 규정)출발점은 법 제29조입니다.개인정보처리자는 개인정보가 유출등이 되지 아니하도록 내부 관리계획 수..

서버 취약점 점검 결과표를 받으면 계정 관리 항목이 거의 빠지지 않고 들어 있습니다. 퇴사자 계정이 그대로 있다, 테스트 계정에 비밀번호가 없다, root 말고도 UID가 0인 계정이 있다. 하나같이 고치는 데 1분도 안 걸리는 문제인데, 서버가 수십 대가 되면 아무도 들여다보지 않습니다. 그 틈에 침입자가 이름만 그럴듯한 UID 0 계정을 하나 남겨 두면, 계정 목록을 훑어보는 것만으로는 눈치채기 어렵습니다. 결론부터 말하면 이 세 가지는 파일 두 개와 awk 한 줄씩이면 전부 찾을 수 있습니다./etc/passwd와 /etc/shadow에서 볼 칸 (개념)리눅스 계정 정보는 두 파일에 나뉘어 있습니다. /etc/passwd는 누구나 읽을 수 있는 계정 목록이고, /etc/shadow는 root만 읽을..

암호화 요건 회의에서 자주 나오는 질문이 있습니다. "공개키 암호가 더 안전하다던데, 그냥 RSA로 전부 암호화하면 안 되나요?" 반대로 "AES 하나면 충분한데 인증서는 왜 필요하냐"는 질문도 나옵니다. 둘 다 그럴듯하지만, 실제로 해 보면 RSA는 1MB 파일 하나도 한 번에 못 담고, AES는 키를 상대에게 건네는 순간부터 막힙니다. 그래서 TLS, 이메일 암호화, 파일 암호화 도구는 거의 예외 없이 둘을 섞어 씁니다. 결론부터 말하면 둘은 경쟁 관계가 아니라 서로의 약점을 메우는 짝이고, 그 이유는 OpenSSL 명령 몇 줄이면 숫자로 확인할 수 있습니다.키 하나 vs 키 한 쌍, 무엇이 다른가 (개념)대칭키는 잠그는 열쇠와 여는 열쇠가 같습니다. 집 열쇠를 복사해 가족에게 나눠 주는 방식이에요...

보안 점검에서 흔히 지적되는 사례가 있습니다. 데이터는 AES-256으로 잘 암호화해 놓고, 정작 키는 설정 파일에 평문으로 적어 둔 경우입니다. 암호문과 키가 같은 서버, 같은 백업에 있다면 자물쇠와 열쇠를 한 상자에 담아 둔 셈이에요. 암호화의 성패는 알고리즘이 아니라 키를 언제 만들고, 어디에 두고, 언제 버릴지에서 갈립니다. 키 한 벌이 태어나서 파기될 때까지를 OpenSSL로 직접 따라가 보면, 키가 새는 지점은 생각보다 뻔한 곳에 있습니다.키도 태어나고 은퇴한다, NIST의 키 상태 (개념)NIST SP 800-57 Part 1 Rev. 5는 키가 거치는 상태를 여섯 가지로 나눕니다.상태의미Pre-activation생성됐지만 아직 사용 승인 전Active암호화와 복호화 모두 가능Suspende..

인증서 교체 작업을 맡으면 보통 압축 파일 하나를 받습니다. 열어 보면 .key, .csr, .crt, .pem, .pfx가 섞여 있고, 어떤 건 텍스트인데 어떤 건 열면 깨진 글자만 나옵니다. 여기서 파일을 잘못 고르면 서버가 안 뜨거나, 떠도 일부 클라이언트에서만 "신뢰할 수 없는 인증서" 경고가 납니다. 인증서 장애는 대부분 기술이 어려워서가 아니라 파일이 뭔지 확인하지 않고 넣어서 생깁니다. 그 확인을 전부 OpenSSL 명령 몇 줄로 끝낼 수 있다면, 교체 작업이 훨씬 덜 무섭지 않을까요?인증서 파일들의 관계 (개념)인증서 발급은 네 가지 재료로 이뤄집니다.파일정체외부에 줘도 되나개인키 (.key)서버만 갖는 비밀 값절대 안 됨CSR (.csr)공개키 + 도메인 정보, 개인키로 서명한 발급 신청..

공인 IP로 SSH 포트를 열어 둔 서버에 들어가 인증 로그를 열어 보면, 처음 보는 계정 이름으로 로그인 실패가 수백 줄씩 쌓여 있는 경우가 흔합니다. admin, test, oracle 같은 이름들이죠. 대부분은 인터넷 전체를 훑는 자동화 스캐너가 남긴 흔적이라 그냥 넘기기 쉽습니다. 문제는 그 수백 줄 사이에 진짜로 성공한 한 줄이 섞여 있을 때입니다. 그 한 줄을 골라내는 눈이 있는지가 서버 담당자와 보안담당자를 가르는 차이예요. 로그 한 줄 한 줄이 무슨 뜻인지부터 시작해서, 공격 패턴을 집계하고 자동으로 막는 데까지 가 보겠습니다.인증 로그는 어디에, 어떻게 쌓이나 (개념)리눅스에서 SSH 로그인, sudo, su, 계정 생성 같은 인증 관련 이벤트는 syslog의 auth·authpriv 분..