2026/02
식약처 애플리케이션 보완 서류 작성
외부 업체와 앱인앱 문서 주고 받음
애플리케이션에 모 회사 체중계 연동, 커스텀 uuid라서 다른 프로젝트 만들어서 연동했는데 몇 가지 신경 쓰이는 방법이 고민거리
기존 애플리케이션을 분기해서 개발하려고하다가 거의 대부분의 로직을 제거하고 블루투스 통신만 활용하면 되기에 lite 버전을 만들어서 새로 구현하고 전달함
app-in-app이라는 구조인데 Explicit Intent와 json을 통해서 우리 애플리케이션에서의 값을 상대 업체 애플리케이션을 보내줌
회사 홈페이지에 data.go.kr로 주가를 받고 있었는데, 이게 지연이기도하고 해서 네이버 주식에서 파싱해서 쓰는 방법을 하기로 했다
https://stock.naver.com/api/domestic/detail/회사번호/detail?codeType=KRX
이걸 서버에서 장이 시간되면 1~60분 마다 요청하고 저장한 뒤에, 이걸 반영한다.
선택할 수 있는 사항
- 곱게 증권사 api를 받는다
- 서버에 저장한다
1를 기다리는 시간보다 2로 빠르게 구현하고 싶었다. 상장사 IR 화면에 빈 값을 두고 싶지 않았다. 그래서 cloudflare workers와 hono를 이용해서 월-금 유효한 시간대에 1분마다 요청한 다음 그것을 저장하고, IR 화면에서 그것을 불러오는 방식이다
여기서 다시 배운점은 fetch에 대해서이다. 멍 때리면서 요청하고 값을 기다렸는데 값이 안오길래 뭐지하고 봤더니 fetch를 한 값은 response.json()를 통해서 열어줘야한다. 즉, 편지 봉투라면 fetch(url).then(response => response.json()).then(data => console.log(data))
- fetch(url) 편지 도착
- .then(response => response.json()) 편지 봉투 개봉(이 때 뭘 주는지 모르니 따로 요청해야함) 그래서 .json()/JSON, .text()/문자열, .blob()/파일, .arrayBuffer()/바이너리 이런 식으로 해석할 수 있다. HTTP는 조각들이 오기 때문.
- .then(data => console.log(data)) 편지 내용 확인 이런 절차가 필요하다는 걸 배웠다
개발 거버넌스 작성
- https://zenn.dev/catnose99/articles/547cbf57e5ad28
- https://news.hada.io/topic?id=26113
- ISMS-P
- ISO27001
- OWASP ASVS (Application Security Verification Standard): 웹 보안
- OWASP MASVS (Mobile Application Security Verification Standard): 앱(iOS/Android) 보안 표준
참조해서 작성해달라고 요청함
🛡️ 프로젝트 보안 거버넌스 마스터 체크리스트
1. 관리 체계 및 거버넌스 (Governance & Compliance)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 1 | 정보자산 식별 | 모든 서버, DB, 앱 소스코드, 기기 펌웨어를 자산 리스트에 등록하고 관리함 |
| 2 | 환경 분리 | 개발/테스트 환경과 운영 환경을 물리적 또는 논리적으로 완전히 격리함 |
| 3 | 최소 권한 원칙 | 모든 계정에 업무 수행에 필요한 최소한의 권한만 부여하고 주기적으로 검토함 |
| 4 | 직무 분리 | 개발, 운영, 보안 담당자의 역할을 분리하여 상호 견제 체계를 구축함 |
| 5 | 사고 대응 절차 | 침해 사고 발생 시 보고, 분석, 복구 단계가 포함된 매뉴얼을 수립하고 훈련함 |
| 6 | 위탁업체 관리 | 외부 개발사 및 인프라 업체와 보안 서약서 및 개인정보 처리 위탁 계약을 체결함 |
| 7 | 퇴사자 처리 | 인사 변동 발생 시 모든 시스템 권한을 즉시(최대 24시간 내) 삭제함 |
| 8 | 취약점 점검 | 연 1회 이상 정기적으로 모의 해킹 및 인프라 취약점 점검을 수행하고 조치함 |
| 9 | 공급망 관리 | 오픈소스 및 외부 라이브러리 목록(SBOM)을 관리하고 보안 업데이트를 상시 적용함 |
| 10 | 법규 준수 검토 | 개인정보보호법 및 식약처 사이버보안 가이드라인 준수 여부를 정기 확약함 |
2. 인증 및 계정 관리 (Authentication & Access Control)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 11 | 비밀번호 해싱 | Argon2, bcrypt 등 강력한 알고리즘과 고유한 Salt를 조합해 암호화 저장함 |
| 12 | 비밀번호 정책 | 8자 이상, 문자/숫자/특수문자 조합 강제 및 주기적 변경 정책을 적용함 |
| 13 | MFA 의무화 | 인프라 제어 및 관리자 계정 접속 시 OTP, FIDO 등 다요소 인증을 필수 적용함 |
| 14 | 로그인 제한 | 연속 실패 시 계정 잠금 또는 지연 시간을 적용하여 무차별 대입 공격을 차단함 |
| 15 | 세션 타임아웃 | 무활동 세션에 대해 자동 로그아웃을 설정함 (관리자 15분, 일반 유저 30분 권장) |
| 16 | 세션 고정 방지 | 로그인 시마다 세션 ID를 새로 발급하여 세션 하이재킹 공격을 무력화함 |
| 17 | 쿠키 보안 설정 | 모든 인증 쿠키에 HttpOnly, Secure 속성을 부여하여 가로채기를 방지함 |
| 18 | SameSite 쿠키 | CSRF 공격 방지를 위해 쿠키에 SameSite=Strict 또는 Lax 속성을 부여함 |
| 19 | 비밀번호 찾기 | 본인 확인 후 유효시간이 매우 짧은 일회용 링크(Magic Link)를 통해서만 재설정함 |
| 20 | 중복 로그인 제어 | 동일 계정의 다중 접속을 제한하거나 새로운 접속 발생 시 사용자에게 알림 |
3. 웹 프론트엔드 보안 (Web Security - React, Vue)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 21 | XSS 방어 | 모든 사용자 출력값은 자동 이스케이프 처리하며 v-html 등 위험 함수 사용을 금함 |
| 22 | CSP 적용 | Content-Security-Policy를 설정하여 승인되지 않은 도메인의 스크립트 실행을 차단함 |
| 23 | HSTS 강제 | 브라우저가 첫 접속부터 HTTPS만 사용하게 하여 다운그레이드 공격을 방지함 |
| 24 | 클릭재킹 방어 | X-Frame-Options: DENY 설정을 통해 iFrame 삽입 공격을 원천 차단함 |
| 25 | No-Sniff 설정 | X-Content-Type-Options: nosniff로 파일 타입 위장 공격을 차단함 |
| 26 | Referrer 정책 | 외부 링크 이동 시 내부 URL 구조가 유출되지 않도록 Referrer-Policy를 엄격히 설정함 |
| 27 | 노오픈너 설정 | 외부 링크 오픈 시 rel="noopener noreferrer"를 강제하여 부모 창 권한 탈취 방지 |
| 28 | SRI 무결성 | 외부 CDN 로드 시 해시값(SRI)을 대조하여 파일 변조 여부를 확인 후 실행함 |
| 29 | 소스맵 제거 | 프로덕션 빌드 시 .map 파일을 완전히 삭제하여 원본 코드 노출을 방지함 |
| 30 | 권한 정책 설정 | Permission-Policy를 통해 카메라, 마이크 등 브라우저 기능 사용 범위를 제한함 |
| 31 | 하드코딩 금지 | JS 코드 내부에 API Key, 테스트 계정, 내부 IP 정보를 포함하지 않음 |
| 32 | 서버 측 검증 | 모든 보안 로직(가격, 권한 등)은 클라이언트가 아닌 서버에서 최종 확인됨 |
| 33 | 자동 완성 차단 | 민감 정보 입력 필드에 autocomplete="off"를 설정하여 정보 남김을 방지함 |
| 34 | 라이브러리 스캔 | npm audit 등을 빌드 프로세스에 통합하여 취약한 패키지 포함을 자동 차단함 |
| 35 | 비정상 요청 차단 | 브라우저 레벨에서 비정상적인 대량 요청 시도를 탐지하고 차단하는 로직 보유 |
4. 모바일 앱 및 블루투스 보안 (Mobile & BLE)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 36 | 코드 난독화 | R8, DexGuard 등을 사용하여 바이너리 역공학 및 로직 분석을 매우 어렵게 함 |
| 37 | 기기 위변조 탐지 | 루팅/탈옥된 기기에서 앱 실행 시 민감 기능을 차단하거나 앱을 안전 종료함 |
| 38 | 보안 저장소 활용 | 암호화 키와 토큰은 반드시 Keychain(iOS) 또는 Keystore(Android)에만 저장함 |
| 39 | SSL Pinning | 서버 인증서 공개키를 앱에 고정하여 가짜 인증서를 통한 가로채기(MITM) 차단 |
| 40 | 캡처 방지 | 의료/개인정보 노출 화면에서 시스템 API를 호출하여 화면 캡처 및 녹화를 금지함 |
| 41 | 스냅샷 보호 | 앱 전환 시 노출되는 스냅샷 화면을 마스킹하거나 블러 처리하여 정보 노출 방지 |
| 42 | Hermes 컴파일 | React Native 소스 코드를 바이트코드로 컴파일하여 배포함으로써 노출을 최소화함 |
| 43 | BLE Bonding 강제 | 기기 간 페어링(Bonding) 과정을 필수로 거치고 암호화 채널에서만 명령 수행 |
| 44 | BLE 종단간 암호화 | 블루투스 기본 암호화 외에 앱 레이어에서 AES-GCM 등으로 데이터를 재암호화함 |
| 45 | 재전송 공격 방지 | 모든 명령 패킷에 Nonce 또는 타임스탬프를 포함하여 패킷 재사용을 방지함 |
| 46 | MAC 주소 랜덤화 | RPA(Resolvable Private Address)를 사용하여 기기의 위치 추적 시도를 차단함 |
| 47 | 근접 제어 인증 | RSSI 신호 세기를 감지하여 기기가 실제 사용자 근거리에 있을 때만 작동을 허용함 |
| 48 | 펌웨어 서명 확인 | FOTA(무선 업데이트) 시 디지털 서명을 검증하여 공식 배포본만 설치되게 함 |
| 49 | 안전한 초기화 | 기기 양도/반납 시 내부 데이터와 연결 정보를 완전히 삭제하는 기능을 제공함 |
| 50 | 물리 포트 보안 | 기기 하드웨어의 JTAG, UART 등 디버깅 포트를 물리적으로 차단함 |
5. 백엔드 및 API 보안 (API Security)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 51 | 엄격한 타입 검증 | Pydantic 등으로 정의되지 않은 필드나 잘못된 데이터 타입 유입을 서버 단에서 차단 |
| 52 | SQL 인젝션 방어 | 모든 DB 요청에 Prepared Statement 또는 ORM을 사용하고 동적 쿼리를 금지함 |
| 53 | API Rate Limit | IP 및 유저별 호출 횟수를 제한하여 무차별 대입 및 서비스 거부 공격을 방어함 |
| 54 | CORS 정교화 | 모든 도메인(*) 허용을 금지하고 승인된 화이트리스트 도메인만 통신을 허용함 |
| 55 | ID 기반 탈취 방지 | 요청된 리소스 ID가 현재 세션 유저의 소유가 맞는지 모든 API에서 필수로 검증함 |
| 56 | SSRF 공격 차단 | 외부 URL 요청 시 내부망 IP(127.0.0.1 등)로의 접근을 금지하는 필터를 적용함 |
| 57 | 에러 정보 은닉 | API 실패 시 시스템 내부 정보나 스택트레이스를 노출하지 않고 고유 코드만 반환 |
| 58 | 응답 데이터 필터링 | 응답 객체에서 비밀번호, 내부 관리용 ID 등 민감 필드가 자동 제외되도록 DTO 구성 |
| 59 | 파일 업로드 보안 | 확장자 체크, 파일명 난독화, 실행 권한 없는 스토리지 저장 및 스캔을 수행함 |
| 60 | 멱등성 보장 | 중복 요청으로 인한 중복 처방/결제를 막기 위해 멱등성 키 검증 로직을 도입함 |
| 61 | 역직렬화 보안 | 신뢰할 수 없는 데이터의 자동 객체화 기능을 비활성화하고 화이트리스트 방식 적용 |
| 62 | 토큰 로테이션 | Access Token은 짧게 유지하고, Refresh Token은 사용 시마다 새로 발급함 |
| 63 | 보안 미들웨어 | 모든 API 응답에 공통 보안 헤더가 포함되도록 서버 프레임워크 수준에서 강제함 |
| 64 | 봉투 암호화 | 데이터 암호화 시 마스터 키(KMS)로 보호된 데이터 키를 사용하는 방식을 적용함 |
| 65 | 정상 종료 구현 | 서버 종료 시 현재 요청을 안전하게 마무리하는 Graceful Shutdown을 구현함 |
6. 데이터베이스 및 저장소 보안 (Database)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 66 | 행 수준 보안 (RLS) | 동일 테이블 내에서도 본인의 데이터 행에만 접근 가능하도록 DB 수준에서 격리 |
| 67 | 필드 단위 암호화 | 의료 기록 등 극민감 컬럼은 DB 암호화와 별개로 앱 레벨에서 2중 암호화 저장 |
| 68 | 정밀 감사 로그 | 개인정보 접근/변경 시 쿼리 내용과 수행자 정보를 상세히 기록하여 보존함 |
| 69 | DB 접속 격리 | DB 서버를 외부망에서 완전히 차단하고 허용된 서버 IP에서만 접속하게 통제함 |
| 70 | SQLite 암호화 | 모바일 기기에 저장되는 SQLite 파일은 SQLCipher 등을 통해 전체 암호화함 |
| 71 | 저장 데이터 암호화 | EBS, RDS 등 모든 저장소에 대해 KMS 마스터 키를 이용한 전체 암호화를 적용함 |
| 72 | 최소 권한 계정 | 앱 계정은 Root가 아닌 특정 테이블의 CRUD 권한만 부여된 제한적 계정을 사용함 |
| 73 | 불변 백업 설정 | 백업 파일이 일정 기간 동안 삭제/수정되지 않도록 S3 Object Lock 등을 적용함 |
| 74 | 복구 테스트 실시 | 매월 정기적으로 백업 파일을 이용한 실제 복구 테스트를 수행하여 무결성 확인 |
| 75 | 비식별화 가이드 | 통계 목적 추출 시 개인 특정 요소를 제거하거나 가명화 처리 가이드를 준수함 |
7. 사진 및 미용 데이터 보안 (Photo & Demographics)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 76 | 이미지 EXIF 제거 | 사진 업로드 즉시 GPS 위치 및 촬영 기기 정보 등 메타데이터를 서버에서 삭제함 |
| 77 | 서명된 URL 제공 | 이미지 접근 시 공개 URL 대신 짧은 시간만 유효한 Signed URL을 생성하여 제공 |
| 78 | 이미지 파일 암호화 | 사진 파일 자체를 암호화하여 저장소 유출 시에도 원본을 볼 수 없도록 처리함 |
| 79 | 동적 워터마킹 | 사진 조회 화면에 접속자 ID와 시간이 포함된 투명 워터마크를 실시간으로 합성함 |
| 80 | 얼굴 비식별 처리 | 보존 목적 외의 사진은 눈/코/입 외 배경을 자동 블러 처리하여 가명화함 |
| 81 | 통계 데이터 범주화 | 나이를 정확한 숫자가 아닌 '20대 후반' 등으로 범주화하여 저장해 식별성 낮춤 |
| 82 | 별도 동의 확보 | 얼굴 사진 등 생체 인식 정보 수집 시 일반 약관과 분리된 명시적 동의를 받음 |
| 83 | 데이터 결합 차단 | 고객 식별 정보 DB와 사진 데이터 DB를 분리하고 매칭 키는 별도 관리함 |
| 84 | AI 학습 보안 | AI 모델 학습 시 고객 식별자를 완전히 제거하고 가명 처리된 데이터셋만 활용함 |
| 85 | 데이터 다이어트 | 분석이 끝난 원본 사진은 즉시 삭제하거나 법정 보존 기간 후 자동 파기함 |
8. 인프라 및 클라우드 보안 (Infrastructure)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 86 | S3 퍼블릭 차단 | 모든 S3 버킷의 퍼블릭 액세스를 기본 차단하고 OAC 등을 통해서만 접근 허용 |
| 87 | 내부 서브넷 배치 | WAS 및 DB 서버를 인터넷 접속이 불가능한 Private Subnet에 배치하여 격리함 |
| 88 | IMDSv2 강제 | EC2 메타데이터 서비스 버전을 2로 고정하여 SSRF를 통한 권한 유출을 방지함 |
| 89 | 아웃바운드 통제 | 서버에서 외부로 나가는 통신을 승인된 도메인/IP로 제한하여 C&C 통신 차단 |
| 90 | OS 보안 강화 | CIS Benchmark 기준에 따라 불필요 서비스를 제거하고 보안 설정을 강화함 |
| 91 | 중앙 집중형 로깅 | 모든 시스템 로그를 SIEM 시스템으로 실시간 전송하여 침입 흔적 변조를 방지함 |
| 92 | 시크릿 매니저 활용 | API Key 등 중요 정보를 코드나 환경변수에 두지 않고 전용 시크릿 관리 도구 사용 |
| 93 | 비특권 컨테이너 | Docker 프로세스가 호스트 루트 권한을 갖지 않도록 유저 권한으로 실행(Rootless) |
| 94 | VPN 전용 관리 | 서버 관리 접속(SSH)은 오직 승인된 VPN 또는 Bastion 호스트를 통해서만 허용 |
| 95 | WAF/DDoS 보호 | 웹 방화벽과 DDoS 방어 서비스를 전면에 배치하여 인프라 가용성을 확보함 |
9. 백오피스 및 운영 보안 (Backoffice & Ops)
| 번호 | 체크 항목 | 상세 기술 지침 및 보안 이유 |
|---|---|---|
| 96 | 관리자 MFA 필수 | 백오피스 로그인 시 반드시 2차 인증(OTP 등)을 거치도록 강제함 |
| 97 | 마스킹 출력 | 이름, 연락처 조회 시 기본적으로 마스킹 처리하여 보여주고 상세 조회 시 기록함 |
| 98 | 교차 승인 절차 | 중요 설정 변경이나 환자 데이터 수정 시 2인 이상의 승인을 거치는 체계 구축 |
| 99 | 다운로드 통제 | 대량 데이터 다운로드 시 사유 입력 및 상급자 사후 승인 절차를 시스템화함 |
| 100 | 상시 워터마크 | 모든 관리자 화면 배경에 접속자 정보 워터마크를 상시 노출하여 캡처 유출 대비 |
| 101 | 상세 행위 감사 | 관리자의 모든 클릭 및 데이터 조회 행위를 원본 값과 함께 감사 로그로 기록함 |
| 102 | 전용망 접속 | 일반 인터넷망에서 백오피스 접속을 차단하고 사내망/전용 VPN만 허용함 |
| 103 | 세션 타임아웃 단축 | 관리 시스템의 세션 유효 시간을 짧게 설정하여 자리 비움 사고를 방지함 |
| 104 | 인사 정보 연동 | 퇴사 발생 시 인사 시스템과 연동하여 모든 백오피스 권한이 즉시 정지되게 함 |
| 105 | 보안 최종 승인 | 프로젝트 배포 전 위 모든 항목이 준수되었음을 보안 담당자가 최종 서명함 |
💡 담당자 실무 가이드
- 엑셀 활용: 위 카테고리별 테이블을 엑셀 시트로 복사하여 [준수 / 미준수 / 해당없음 / 비고] 컬럼을 만들어 관리하세요.
- 증적 확보: ISMS-P 등 인증 심사 시에는 실제 설정 화면이나 코드가 증거가 되므로, 각 항목 옆에 증적 자료 경로를 적어두면 매우 유용합니다.
- 유연한 적용: 서비스의 민감도에 따라 필수 항목과 권장 항목을 나누어 개발팀과 협의하십시오.
추가 읽읅거리
- https://www.kisec.kr/bbs_shop/list.htm?me_popup=&auto_frame=&cate_sub_idx=0&search_first_subject=&list_mode=board&board_code=rwdboard&keyfield=&key=&page=&y=&m=
- https://www.boho.or.kr/kr/bbs/list.do?searchCnd=&bbsId=B0000127&searchWrd=&menuNo=205021&pageIndex=1&categoryCode=
- https://www.kisa.or.kr/2060204?page=1
회사 메일 중에 종종 에러 때문에 리턴이 온다
The attached message was undeliverable.
while talking to [0.0.0.0:25]
<<< RCPT TO: qwer@zxcv.com
>>> 550
No such user here (connected from zxcv.com)
******************** Message Summary ********************
From: abc@xyz.com
평판 및 설정 조회
- https://mxtoolbox.com/
- https://senderscore.org/
- https://talosintelligence.com/
- https://spam.kisa.or.kr/spam/spf/spfWrtChk.do?mi=1016#?mi=1091
이곳을 통해서 부족한 설정 spf, dmarc 등등 채웠다
DMARC 레코드가 없으면 이메일 인증이 약해 수신 서버가 의심스러운 메일로 간주하고 550 에러를 반환할 수 있다한다.
SPF => 발신 IP가 도메인 소유자가 허용한 서버인지 확인, 위조 IP로 스팸 보내는 걸 차단 (예: 서버 IP 등록)
DKIM => 메일 내용이 전송 중 변조되지 않았는지 디지털 서명 확인, 해커가 중간에 내용 바꾸는 걸 막음
DMARC => SPF+DKIM 결과 종합 + 실패 시 정책 적용 (quarantine/reject), "이 메일 진짜냐?" 최종 판정
MX => 메일 서버 우선 순위
추가 읽을거리
- https://support.google.com/a/answer/2466580?hl=ko&visit_id=639063739855421550-3735169215&rd=1
- https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-dmarc-record/
- https://datatracker.ietf.org/doc/html/rfc7489
- https://dmarc.org/wiki/FAQ
- https://library.gabia.com/contents/groupware/8235/
- https://news.hada.io/topic?id=15408
- https://news.hada.io/topic?id=11154
- https://news.hada.io/topic?id=14880
- https://news.hada.io/topic?id=5720
더존측 서버 ip가 블랙리스트에 들어가 있는데 dkim까지도 없어서 메일이 도착하지 못하길래 dkim 을 받고 도메인에 txt로 넣고, ip 블랙리스트 해결해달라고 메일했음
git commit -m vs git commit -am 에 대해 알게됨
그간 git add 파일 => git commit -m "msg" 였는데 git commit -am "msg"하면 이걸 한 번에 할 수 있다는 것을 알았음
그 외로도
| 명령어 | 용도 | 특징 |
|---|---|---|
| bisect | 버그 발생 시점 찾기 | 이진탐색 |
| blame | 누가 언제 변경했는지 | 줄별 이력 |
| revert | 커밋 안전 되돌리기 | 새 커밋 생성 |
| cherry-pick | 특정 커밋 가져오기 | 다른 브랜치에서 선택 복사 |
- feature 브랜치의 특정 커밋만 main으로 가져오기
git checkout main
git cherry-pick a1b2c3d4 # 원하는 커밋 해시
가 있음