728x90
🐬 날으는물고기
🐬 최근 게시글
-
여행 전 스마트폰 준비 — eSIM·오프라인 지도·백업·결제, 떠나기 전날 30분 체크 여행 준비물 목록에 옷과 어댑터는 있는데 스마트폰 설정은 빠져 있는 경우가 많습니다. 그런데 현지에서 가장 자주 곤란한 것이 바로 폰입니다 — 데이터가 안 되고, 지도가 안 열리고, 결제가 막히고, 인증 문자를 못 받습니다. 떠나기 전날 30분이면 대부분을 미리 막을 수 있습니다.1. 데이터 — 로밍·eSIM·현지 유심 가운데 하나를 미리 정한다요즘은 eSIM 이 가장 균형이 좋습니다. 출발 전 집에서 설치하고, 도착해서 데이터 회선만 eSIM 으로 바꾸면 됩니다. 원래 번호는 그대로 살아 있어 문자 인증을 받을 수 있습니다(수신 로밍 요금은 통신사별로 다르니 확인). 현지 유심은 가장 싸지만 번호가 바뀌어 은행·메신저 인증이 막힐 수 있고, 뺀 유심을 잃어버리기 쉽습니다. 무엇을 쓰든 출발 전에 설정 ..
-
디지털 짐 정리 주말 플랜 — 사진·파일·구독·계정을 한 번에 가볍게 방 정리는 눈에 보여서 하게 되는데, 디지털 짐은 보이지 않아서 쌓입니다. 사진 수만 장, 다운로드 폴더의 설치 파일, 언제 가입했는지 모를 서비스, 잊고 결제되는 구독. 주말 하루 반이면 대부분 정리됩니다. 아래는 네 블록으로 나눈 실제 플랜입니다. 한 블록은 두 시간을 넘기지 않습니다.토요일 오전 — 사진사진 앱의 '중복'·'스크린샷'·'흐린 사진' 보기 기능을 먼저 씁니다. 스크린샷은 대부분 그때 필요했던 것이라 통째로 지워도 됩니다. 그 다음 월별로 넘기며 같은 장면 연사는 하나만 남깁니다. 끝으로 클라우드 백업이 켜져 있고 용량이 남아 있는지 확인합니다. 사진 정리의 목표는 '예쁜 앨범'이 아니라 백업이 끊기지 않을 용량 확보입니다.토요일 오후 — 파일다운로드 폴더와 바탕화면을 비웁니다. 설치 ..
-
생성형 AI 를 업무에 쓸 때 정보 유출 막기 — 사내 이용 가이드라인 만드는 법 직원들은 이미 생성형 AI 를 쓰고 있습니다. 금지하면 개인 계정으로 몰래 쓰는 '섀도우 AI' 가 되고, 그 편이 훨씬 위험합니다. 현실적인 답은 써도 되는 도구와 넣어도 되는 정보를 분명히 정해 주는 것입니다. 가이드라인은 길 필요가 없습니다. 아래 네 가지가 들어가면 됩니다.1. 무엇을 넣으면 안 되는가 — 데이터 등급으로가장 중요한 한 줄은 "고객 개인정보·비밀 정보는 넣지 않는다" 입니다. 이미 데이터 분류 등급(공개·내부·비밀 등)이 있다면 그 등급표에 'AI 입력 가능 여부' 열을 하나 더하면 끝납니다. 소스코드는 특히 주의합니다 — 코드 조각에 API 키·내부 호스트명·DB 접속 정보가 섞여 들어가는 일이 잦습니다. 예시 데이터는 가명 처리하거나 만들어 쓰도록 안내합니다.2. 어떤 도구를 ..
-
스마트폰 분실에 미리 대비하기 — 잠금·원격 찾기·백업·유심 보호 설정 스마트폰을 잃어버리면 기기값보다 그 안의 것 — 은행 앱, 인증 문자, 사진, 메신저 — 이 문제입니다. 다행히 요즘 폰은 미리 켜 두기만 하면 분실 뒤에도 대부분을 지킬 수 있는 기능을 다 갖추고 있습니다. 문제는 켜 두지 않는다는 것. 오늘 10분이면 됩니다.1. 화면 잠금 — 패턴보다 PIN, 그리고 생체인증패턴은 화면의 손자국으로 추측되기 쉽고 어깨너머로도 잘 보입니다. 6자리 이상 PIN 을 기본으로 두고, 일상에서는 지문·얼굴로 엽니다. 설정에 '잠금 해제 10회 실패 시 초기화' 옵션이 있으면 켭니다. 잠금 화면에서 알림 내용(인증번호 등)이 보이지 않게 하는 것도 중요합니다 — 잠긴 폰이라도 문자 인증번호가 화면에 뜨면 소용이 없습니다.2. 원격 찾기 기능 — 분실 뒤에 켤 수는 없다And..
-
웹 취약점 점검 시작하기 — OWASP Top 10 을 기준으로 한 점검 순서와 기록 방법 웹 취약점 점검을 처음 맡으면 도구부터 찾게 되지만, 도구보다 먼저 정해야 할 것은 순서와 기록 방법입니다. OWASP Top 10 은 '무엇을 볼 것인가'의 목록으로 쓰기 좋고, 여기에 '어떤 순서로 보고 어떻게 적는가'를 더하면 혼자서도 꽤 체계적인 점검이 됩니다. 이 글은 허가받은 자기 서비스(또는 계약된 범위)를 점검한다는 전제입니다. 허가 없는 점검은 하지 않습니다.0. 시작 전 — 범위와 계정을 서면으로어떤 도메인·기능이 범위인지, 어떤 등급의 계정을 몇 개 쓸지(일반 2개 이상·관리자 1개가 좋습니다), 점검 시간대, 운영 데이터 보호 방법(테스트 데이터만 생성·삭제)을 적어 합의합니다. 점검 중 문제가 생겼을 때 연락할 사람도 정합니다.1. 정찰 — 기능 목록 만들기로그인·가입·비밀번호 찾..
-
접근 권한 검토(Access Review) 분기 운영 절차 — 누가, 무엇을, 왜 가지고 있는가 접근 권한은 늘어나기만 합니다. 부서를 옮겨도 예전 권한이 남고, 프로젝트가 끝나도 시스템 계정은 살아 있고, 급하게 받은 관리자 권한은 돌려주는 사람이 없습니다. 그래서 주기적으로 "이 권한이 아직 필요한가"를 묻는 절차가 필요하고, 이것이 접근 권한 검토입니다. 인증 통제 항목이기도 하지만, 실제 사고(퇴직자 계정·과다 권한)를 줄이는 효과가 가장 분명한 운영 활동이기도 합니다.1. 무엇을 검토하나 — 계정 × 권한 목록시스템마다 '누가 어떤 권한을 가졌는가'를 표로 뽑습니다. 사람 계정만이 아니라 서비스 계정·공용 계정·외주 계정도 포함합니다. 처음에는 핵심 시스템(인사·재무·고객정보·운영 서버·클라우드 콘솔)부터 시작하고, 범위를 분기마다 넓히는 편이 현실적입니다.2. 누가 검토하나 — 권한을 쓰..
-
개인정보 처리방침, 빠지기 쉬운 항목 점검 — 담당자가 분기마다 보는 체크리스트 개인정보 처리방침은 '한 번 올려 두면 끝'인 문서가 아니라 실제 처리와 늘 같아야 하는 문서입니다. 그런데 서비스는 계속 바뀌고 방침은 그대로 남아, 점검을 나가 보면 방침과 실제가 다른 경우가 가장 흔합니다. 담당자가 분기마다 한 번 돌려 볼 항목을 정리했습니다. 법령의 세부 요건은 개인정보보호위원회의 작성 지침을 기준으로 삼고, 여기서는 '어디가 자주 어긋나는가'에 집중합니다.1. 수집 항목·목적 — 화면과 대조한다회원가입·주문·문의 화면에서 실제로 받는 항목을 하나씩 적어 방침의 수집 항목과 비교합니다. 기능이 추가되며 전화번호·생년월일·위치정보가 슬쩍 늘어난 경우가 많습니다. 자동으로 수집되는 항목(접속 기록, 기기 정보, 쿠키)도 빠뜨리지 않습니다.2. 보유기간과 파기'탈퇴 시까지'로만 적혀 ..
-
콘텐츠 보안 정책(CSP) 처음 적용하는 법 — 보고 모드에서 시작해 단계별로 조이기 CSP(Content-Security-Policy)는 "이 페이지는 어떤 출처의 스크립트·스타일·이미지만 실행·표시한다"를 브라우저에 알려 주는 응답 헤더입니다. 제대로 걸리면 XSS 로 주입된 스크립트가 실행 자체가 막히므로 가장 강력한 방어선이 됩니다. 문제는 처음부터 강하게 걸면 사이트가 바로 깨진다는 것. 그래서 보고 모드로 시작해 단계별로 조이는 순서가 정석입니다.1단계 — 보고 모드로 현황 보기Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-reportReport-Only 는 아무것도 막지 않고 위반만 보고합니다. 브라우저 콘솔에도 뜨고, /csp-report 로 JSON 이 POST 됩니다. 이 보고를 일주일쯤..
-
파이썬 requests 로 외부 API 안전하게 호출하기 — 타임아웃·재시도·시크릿·검증 requests.get(url) 한 줄은 잘 돌아가는 것처럼 보이지만, 운영에 들어가면 네 가지 문제가 차례로 찾아옵니다. 상대 서버가 응답을 안 줘서 스레드가 영원히 기다리고, 잠깐의 5xx 에 배치가 통째로 실패하고, 코드에 적힌 API 키가 저장소에 남고, 인증서 경고를 verify=False 로 덮었다가 중간자 공격에 열립니다. 아래는 그 네 가지를 막는 기본 틀입니다.1. 타임아웃은 선택이 아니다requests 는 기본 타임아웃이 없습니다. 연결 타임아웃과 읽기 타임아웃을 튜플로 주세요.resp = session.get(url, timeout=(3, 10)) # 연결 3초, 읽기 10초값은 상대 서비스의 평소 응답 시간에 여유를 더해 정합니다. '넉넉하게 60초'는 장애 때 60초씩 묶이는 ..
-
Nginx 역방향 프록시에 TLS 와 보안 헤더 제대로 붙이기 애플리케이션 앞에 Nginx 를 두는 이유는 TLS 를 한곳에서 끝내고, 보안 헤더를 한곳에서 붙이고, 백엔드는 그 뒤에서 단순하게 두기 위해서입니다. 그런데 '일단 돌아가게' 만든 설정은 보통 이 셋 중 하나가 빠져 있습니다. 아래는 가장 흔한 구성(Let's Encrypt + 백엔드 127.0.0.1:8080)을 기준으로 한 최소한의 올바른 설정입니다.1. 인증서 — certbot 과 자동 갱신sudo apt install certbot python3-certbot-nginxsudo certbot --nginx -d example.com -d www.example.comsystemctl list-timers | grep certbotcertbot 이 server 블록에 인증서 경로를 넣어 줍니다. 갱..
728x90
728x90