728x90
🐬 날으는물고기
🐬 최근 게시글
-
Nginx·Apache 버전·디렉터리 노출 줄이는 점검법 배포 직전 서버 점검에서 자주 빠지는 항목이 응답에 남아 있는 서버 정보입니다. Server 헤더에 nginx/1.18.0 같은 버전이 그대로 보이기도 하고, 존재하지 않는 경로를 요청하면 에러 페이지 하단에 같은 정보가 다시 나오기도 합니다. 공격자는 이 정보를 보고 해당 버전의 알려진 취약점을 먼저 떠올리므로, 노출 범위를 줄이는 것은 점검의 기본입니다.이 글에서는 Nginx와 Apache 설정 파일을 기준으로 세 가지를 확인합니다. Server 헤더의 버전 정보, 디렉터리 리스팅, 에러 페이지 노출입니다. 점검 명령과 설정 예시, 반영 순서를 차례로 다루고, 마지막에 자주 묻는 질문을 정리합니다.응답에서 무엇이 보이는지 먼저 확인합니다설정을 바꾸기 전에 외부에서 보이는 모습부터 기록해 둡니다. 설정..
-
리눅스 sudo 권한 점검법: NOPASSWD·ALL 정리 순서 서버 계정을 점검하다 보면 "sudo 권한을 누가 가지고 있는지 아무도 정확히 모른다"는 상황을 자주 만납니다. 프로젝트가 끝난 뒤에도 배포용 그룹은 그대로 남고, 퇴사자 계정은 지워지지 않으며, 편의를 위해 추가한 NOPASSWD 한 줄이 몇 년째 유지되기도 합니다. ISMS-P 심사에서도 이런 권한이 왜 필요한지, 누가 승인했는지 설명하지 못하면 지적으로 이어지기 쉽습니다.이 글에서는 sudoers 파일과 /etc/sudoers.d 항목, 그룹 기반 권한 부여 현황을 명령어로 확인하는 방법을 정리합니다. 이어서 업무상 필요 없는 NOPASSWD와 ALL 권한을 찾아 줄이고, 변경 근거를 남기는 순서까지 따라 할 수 있도록 구성했습니다. 명령어는 Ubuntu·Debian과 RHEL 계열을 기준으로 하며..
-
사내 생성형 AI에 고객정보·소스 넣기 전 점검법 도입사내에 생성형 AI 챗봇이 들어오면 가장 자주 생기는 일은 직원이 업무를 빨리 끝내려고 고객 명단, 상담 기록, 소스코드를 그대로 붙여 넣는 것입니다. 요약만 시키려는 의도였더라도 입력된 텍스트는 모델이 호스팅된 곳으로 전송되고, 대화 로그로 남을 수 있습니다. 보안 담당자는 사고가 난 뒤에야 알게 되는 경우가 많습니다.이 글에서는 입력 단계에서 마스킹과 차단 규칙을 어떻게 설계할지, 대화 로그의 보관 기간과 접근 권한을 ISMS-P 관점에서 어떻게 점검할지 순서대로 정리합니다. 특정 제품을 추천하지 않고, 개발자와 보안 담당자가 지금 쓰는 환경에 바로 대입해 볼 수 있는 기준과 질문에 집중합니다.직원이 AI에 붙여 넣는 흐름점검은 실제로 어떤 데이터가 어디를 거쳐 가는지 그리는 데서 시작합니다. 흐..
-
학원·체험 신청서에 주민번호가 필요한지 따지는 법 학원이나 체험 행사에 자녀를 등록하려고 신청서를 열면, 주민등록번호 전체, 건강 상태, 알레르기 여부 같은 칸이 나란히 있는 경우가 적지 않습니다. 접수 담당자는 "원래 다 받는 양식"이라고 답하는 경우가 많아, 입력하는 쪽은 문제의식 없이 칸을 채우기 쉽습니다. 그런데 이 정보는 한번 제출되면 복사되고, 출력되고, 여러 시스템으로 넘어가 오래 남을 수 있습니다.이 글은 학부모 입장에서도, 신청서를 설계하고 접수를 관리하는 실무자 입장에서도 쓸 수 있는 판단 기준을 정리합니다. 주민번호를 왜 묻는지 근거를 확인하는 질문, 거절하거나 생략해도 되는 항목을 구분하는 표, 제출 후 보관과 파기를 확인하는 순서를 차례로 다룹니다. 끝까지 읽고 나면 지금 손에 든 신청서에서 무엇부터 물어볼지 바로 정할 수 있습니..
-
잠금화면 접종 알림, 질병명이 새는지 점검하는 법 왜 잠금화면이 문제인가접종 관련 알림은 보통 세 갈래로 나갑니다. 앱 푸시, 병원 예약 시스템이 보내는 문자, 메신저 연동 알림입니다. 발송 주체가 서로 달라서 문구 정책이 한 곳에서 관리되지 않는 경우가 많습니다. 기획자는 '예약 확정'이라는 문구가 안전하다고 생각해도, 실제 제목에는 병원명과 질병명이 함께 들어가 있는 일이 자주 있습니다.잠금화면 노출은 기기 소유자가 의도하지 않은 순간에 일어납니다. 책상에 놓인 기기, 충전 중인 기기, 가족이나 동료와 함께 쓰는 태블릿이 대표적입니다. 개인정보보호법상 건강에 관한 정보는 민감정보로 다루는 것이 일반적이므로, 법적 판단은 개인정보 담당 부서와 함께 확인하세요.가상의 사례입니다. 어떤 예약 서비스가 「[○○내과] 인플루엔자 예방접종 예약이 확정되었습니다..
-
접종 기록 조회 API, 번호만 바꿔도 보이나? IDOR 점검법 접종 기록 조회 API는 보통 로그인한 사용자만 호출할 수 있도록 만듭니다. 그런데 로그인 여부만 확인하고 "이 기록의 주인이 지금 요청한 사람인가"를 확인하지 않으면, 로그인한 누구나 다른 사람의 기록을 볼 수 있게 됩니다. 이것이 객체 참조 취약점(IDOR, Insecure Direct Object Reference)입니다.독감 시즌과 가을 여행 시즌에는 접종 기록 조회 기능이 자주 쓰이고, 기록 ID는 URL이나 응답에 그대로 드러나기 쉽습니다. 이 글에서는 테스트 계정 두 개로 서로의 기록 ID를 교차 요청해 보고, 응답에 화면에 필요 없는 개인정보 필드가 섞였는지 확인하는 방법을 정리합니다. 모든 점검은 허가받은 테스트 환경과 본인 소유 테스트 계정으로만 진행한다는 전제입니다.로그인 뒤에서 ID..
-
연령 판별 데이터, 최소 수집부터 설계하는 법 플랫폼이 민감 콘텐츠 정책을 바꾸면 "이 사용자가 성인인가", "최근에 어떤 콘텐츠를 봤는가" 같은 판별 로직이 한꺼번에 늘어납니다. 기능 하나를 추가하는 것처럼 보이지만, 생년월일과 본인확인 결과, 이용 이력이 같은 파이프라인으로 모이기 시작하면 개인정보가 한곳에 쌓이는 구조가 됩니다.이 글에서는 판별에 꼭 필요한 속성만 받고, 원본 대신 판별 결과만 남기며, 보관기간과 접근권한을 정하는 순서를 다룹니다. 법령 해석이나 정책의 세부 기준은 이 글에서 단정하지 않으니, 최종 기준은 법무·개인정보 담당 부서와 해당 기관의 공지에서 확인하셔야 합니다.판별 질문을 먼저 한 문장으로 고정하세요연령 판별 요구는 보통 "정확한 나이"로 시작하지만, 실제로 서비스가 필요한 답은 "기준 연령 이상인지 여부"인 경우가 ..
-
독감 접종 기록은 민감정보? 수집·동의·접근·보관 점검법 독감 시즌이 시작되면 사내에서 접종 여부를 확인하라는 요청이 자주 들어옵니다. 재택 근무 전환이나 출장, 행사 참여 전에 "접종 완료 증명서를 제출해 주세요"라는 공지가 올라오고, 담당자는 메일로 받은 파일을 엑셀에 옮겨 취합합니다. 이 과정에서 접종 기록은 단순한 업무 메모가 아니라 건강과 관련된 개인정보로 바뀝니다.이 글에서는 예방접종·건강 관련 정보가 개인정보보호법상 민감정보에 해당할 수 있다는 전제에서, 수집 근거, 별도 동의, 접근 권한, 보관 기간을 어떻게 나눠 관리할지 실무 점검 항목으로 정리합니다. 법 적용 여부와 세부 기준은 사업 형태와 데이터 흐름에 따라 달라지므로, 마지막에 확인할 곳도 함께 안내합니다.접종 기록이 민감정보가 되는 순간개인정보보호법 제23조는 건강에 관한 정보를 민감정..
-
예약 폼 입력 검증, 브라우저와 서버의 역할 나누기 독감 예방접종 예약이 몰리는 시기에는 예약 폼에 입력이 집중됩니다. 생년월일을 비워 보내거나, 연락처에 문자를 넣거나, 같은 요청을 여러 번 보내는 일이 실제로 자주 일어납니다. 그래서 입력값을 어디에서 어떻게 확인할지가 실무에서 자주 문제가 됩니다.이 글에서는 HTML 폼의 JavaScript 검증을 사용성 도구로 두고, 신뢰 판단은 서버에서 다시 하는 기준을 정리합니다. 필수값·형식·길이 검증 예시와 클라이언트 검증만 믿을 때 생기는 우회 문제를 함께 봅니다. 끝까지 읽으면 자사 예약 폼을 점검할 순서를 얻을 수 있습니다.브라우저 검증과 서버 검증은 역할이 다릅니다브라우저의 JavaScript 검증은 사용자가 잘못 입력했을 때 바로 알려 주는 용도입니다. 제출 버튼을 누르기 전에 "연락처를 입력해 주..
-
예약 몰림에 버티는 예약 API 점검: 중복·재시도·좌석 경쟁 예방접종 예약 페이지가 열리는 순간 짧은 시간에 평소의 수십 배 요청이 몰리는 일은 드물지 않습니다. 이때 시스템이 느려지는 것보다 더 위험한 것은 같은 좌석이 두 사람에게 확정되거나, 응답이 늦은 클라이언트가 재시도를 거듭해 서버를 더 압박하는 상황입니다. 앞서 웹 워커와 DB 커넥션을 점검했다면, 이제는 예약 API 코드가 동시 요청을 어떻게 처리하는지 봐야 합니다.이 글은 PHP와 Python으로 만든 예약 API를 기준으로 점검 순서를 정리합니다. 레이트리밋을 어느 계층에 걸어야 하는지, 좌석 선점을 트랜잭션과 잠금으로 어떻게 보장하는지, 중복 예약을 멱등성 키와 유니크 제약으로 어떻게 막는지, 재시도를 어디서 끊어야 하는지를 확인 항목과 함께 다룹니다. 코드를 고치기 전에 무엇을 기준으로 확인할..
728x90
728x90