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