Portfolio
Portfolio
Linux·DB·웹 서버 전반에 대한 보안 점검과
모의해킹 기반 취약점 분석을 통해 인프라를 재정비한 프로젝트
본 프로젝트는 공격 시나리오를 기반으로 밥세권 서비스의 보안 취약점을 진단,
운영 환경 전반의 안정성을 확보하는 것을 목표로 진행되었습니다.
HQ ↔ BR 양방향 백업 체계, DB 이중화 구조, PHP 웹 서버 보안 설정을 재구축해, 실제 서비스 환경에서도 신뢰할 수 있는 인프라 구조를 구현했습니다.
본 프로젝트는 사업 제안서·제안요청서(RFP)를 기반으로 요구사항을 정의하고,
주요정보통신기반시설 및 전자금융기반시설 보안 기준을 참고하여
점검 및 개선 항목을 도출했습니다.
밥세권 서비스 인프라를 대상으로
Linux 서버 · DB · 웹 서비스 영역
취약점 점검 및 재구축
침투 시나리오 기반 점검 결과
관리자 페이지 취약점이 확인
서비스 중단 및 데이터 유출 위험
주요정보통신기반시설 및
전자금융기반시설 취약점 진단
가이드를
기반으로 점검 수행
DB 이중화·백업 체계 구축과
웹 서버·관리자 페이지 보안 강화
주요 보안 취약점 제거 및
보안 수준 향상
안정적인 서비스 운영 환경 확보
재해 복구 정책·절차 정립
기존 시스템은 실제 운영 환경과 동떨어진 구조로 인해
장애 대응 및 관리 효율에 한계가 존재했습니다.
관리자 페이지, 인증 로직, 서버 접근 영역에서
실질적인 공격 시나리오 기반 점검의 필요성이 대두되었습니다.
장애·침해 사고 발생 시에도 서비스 연속성을 유지할 수 있는
DB 이중화 및 백업 체계 구축이 요구되었습니다.
개별 기능 중심이 아닌 운영·백업·보안을 하나의 흐름으로
설계하는
접근이 필요했습니다.
기존 환경은 보안·백업·데이터 구조 전반에서 단일 장애점과
운영 리스크가 존재했습니다.
본 프로젝트는 이를 구조적으로 해결하는 것을 목표로 설계되었습니다.
저장형 XSS, CSRF, Session Fixation, 평문 비밀번호 저장 등 관리자 페이지 전반에 보안 취약점이 확인되었습니다.
백업 정책 및 복구 절차가 정의되지 않아 단일 서버 장애 시 즉각적인 복구가 불가능했습니다.
DB 서버 단일 구성으로 인해 장애 발생 시 서비스 전체가 중단되는 구조였습니다.
관리자 페이지 인증·세션 구조를 재설계하고 입력값 검증과 필터링을 적용해 주요 취약점을 제거했습니다.
#모의해킹 #시큐어코딩
HQ ↔ BR 간 rsync 기반 양방향 백업 구조를 설계하고 전체·증분 백업을 자동화했습니다.
#rsync #무결성검증
MariaDB Replication 기반 Master–Slave 이중화 구조를 구축하여 DB 단일 장애점을 제거했습니다.
#MariaDB #Failover
사업 제안서 및 제안요청서를 기반으로
밥세권 서비스의 운영 환경과 보안 요구사항을 정리
점검 범위 및 침투 시나리오 설계
주요정보통신기반시설 취약점 진단 가이드를 참조하여
Linux HQ 서버를 대상으로
계정·권한 관리, root 접근 통제, 패스워드 정책,
접근 제어 및 로깅 설정 등을 점검하고 이행 조치 수행
데이터 무결성과 가용성을 고려한 MariaDB Replication 환경을 구축하고 binlog 설정 및 복제 동작을 검증
금융·정보통신 기반 서비스 운영 환경을 고려해
전체·증분 백업 정책을 수립하고,
SSH Key 기반 자동 백업과
날짜별 백업 관리 스크립트를 적용
모의해킹 결과를 바탕으로
XSS·CSRF·세션 관리 취약점을 개선하고,
주요정보통신기반시설·전자금융기반시설
보안 기준을 참고해 관리자 페이지 보안 수준을 강화
본사와 지사는 동일한 서버 역할 구조를 기준으로 구성되며,
본인은 SFTP, MAIL, DB, WEB, BACKUP 서버 영역을 담당했습니다.
로그 서버(LOG)는 전체 인프라 구조에는 포함되지만,
별도의 팀원이 구축 및 운영을 전담한 영역입니다.
(DNS, DHCP는 공통 네트워크 인프라)
HQ : DB Master · 전체 서비스 기준 데이터 관리
BR : DB Master · 판매자 전용 데이터 관리
HQ : 전체 웹서비스 운영
BR : 고객센터 및 입점 신청 서비스 전담
HQ : 사내 파일 전송 전용서버 · 부서별 접근 제어
BR : 사내 파일 전송 전용서버 · 본사와 동일 정책
HQ : 본사 서버군 로그 수집 · 로컬 감사 목적 운영
BR : 지사 서버군 로그 수집 · 동일 정책 적용
※ 로그 서버 구축 및 분석 환경은 타 팀원이 전담
HQ : 본사 부서별 메일 계정 운영
BR : 지사 부서별 메일 계정 운영
HQ : 모든 서버군 원본 데이터 수신 · DB Slave
BR : 모든 서버군 원본 데이터 수신 · DB Slave
본사(HQ)와 지사(BR) 서버군 간 DB 복제, 백업을
양방향 흐름으로 설계하여 데이터 일관성과 장애 대응 능력을 확보했습니다.
DB Master 장애 발생 시 백업 Slave를 이용하여 서비스 연속성을 유지하도록 Failover 흐름을 설계했습니다.
DB Master 장애 발생 시
서비스 오류 및 로그 이상 징후를
통해
장애 상황을 인지합니다.
DB Slave(백업서버)를 기준으로
쓰기 가능 상태로 전환하여
DB Master 역할을 대체합니다.
웹 서비스 및 애플리케이션의
DB 연결 대상을 Master → Slave로
전환합니다.
Slave 서버를 기준으로
백업 및 로그 수집을 지속하며
복구 및 재동기화를 준비합니다.
장애 대응과 데이터 안정성을 확보하기 위해
DB 이중화와 백업·무결성 검증 체계를 단계적으로 설계·구현했습니다.
Master–Slave 구조 기반
데이터 복제 및 장애 대비 설계
날짜 단위 전체·증분 백업 관리체계 구축
SHA-256 해시 기반 백업 파일
무결성 자동 검증 스크립트
백업 검증 및 복구 절차 정상 완료 확인
본 프로젝트는 단순히 서버를 구축하는 데 그치지 않고,
운영·보안·백업이 하나의 흐름으로 이어지는 구조를 설계하는 데 초점을 두었습니다.
본사와 지사를 분리하면서도 역할과 책임을 명확히 정의함으로써
단일 장애점을 최소화하고,
실제 운영 환경에서도 안정적으로 동작할 수 있는
인프라 구조를 구현했습니다.
이 경험을 통해 기술 선택보다 중요한 것은
왜 이 구조가 필요한지 설명할 수 있는 설계 판단이라는 점을
체감할 수 있었습니다.