서버 및 코드 보안

목적

웹 애플리케이션을 보다 안정적이며, 좋은 성능으로 유지, 운영하면서 동시에 개인정보 등 민감한 데이터를 노출시키거나 탈취당하지 않도록 하기 위해 필요한 사항을 기록한다.

참고 자료

원칙

• 심층방어란? | 계층화된 보안
• 보안 기초
• Twelve-Factor app
• https://velog.io/@dudgus1670/The-Twelve-Factor-app
• https://assu10.github.io/dev/2020/12/27/12factor-app/

WAS

• 웹 서버와 WAS(Web Application Server) | 요즘IT

framework

• cloudflare Automatic-Platform-Optimization
• How to secure wordpress
• Security in Drupal

Twelve-Factor App 방법론

SaaS(software-as-a-service) 애플리케이션의 이식성과 복원력을 높이는 것을 목표로 한다. 서비스 운영 시 다양한 변수들로부터 가능한 자유롭게 구성하여 시간이 지나면서 망가지는 소프트웨어의 유지비용을 줄이는 것을 목표로 한다.

인프라

무료 또는 500원짜리 호스팅부터, 멀티티어 클러스터링까지 인프라 구성은 프로젝트에 규모에 따라 다르다.

DNS, network, Load balancer, web server, application server, database server, file storage

WAF (Web Application Firewall)

• apache modsecurity
• cloudflare waf
• aws waf

웹 서버

• 운영 서버에 대한 네트워크 접근을 통제한다. 접근하기 불편해야 한다. SSH 접근할 수 있는 아이피를 제한해야 한다.
• 운영 서버에 직접 접근하는 것도 위험해서, Bastion Host를 통해 접근하기도 한다.
• 운영 서버 접근 시 작업자, 접근 시간 및 작업 내용을 기록하기도 한다. 비인가 접근을 식별하기 쉽다.
• 운영 서비스 의존성은 항상 최신으로 유지하고 사용 중지한 의존성은 삭제하여 취약점을 가능한 줄여야 한다. sudo apt upgrade, composer remove drupal/devel…
• 웹서버 루트 아래 파일에는 누구나 접근할 수 있다고 생각해야 한다. 디버깅, 개발용 코드, 정보 등이 담긴 파일은 모두 삭제하거나 접근을 제한한다.
• SSL 반드시 사용!
• [정책] 비밀번호 등 계정 탈취 (key파일 포함)

WAS(Web Application Server)

• java, php, ruby, python, node => tomcat, php-fpm, puma, gunicorn, express

데이터베이스 서버

• 테스트나 공개할 수 밖에 없는 경우를 제외하고는 절대 외부에서 바로 접근할 수 없어야 한다.
• RDS 등 서비스형이 아닌 서버 파일시스템에 접근할 수 있는 경우 위의 웹서버 주의사항 똑같이 적용한다.
• TDE(Transparent/External database encryption) - data encryption at rest
• Column-level encryption - (Solutions - Petra, D’Amo, etc.)
• Field-level encryption - (Application level)
• Filesystem-level encryption (TDE)
• Full disk encryption (OS level)
• 암호화 키 서비스 솔루션.

코드

• 귀찮다고 레포지토리에 비밀번호 등 민감한 정보를 커밋하지 않는다.
• 기계와 대화한다고 생각하고 쓰지만 결국 사람이 읽고 유지보수하므로 다음 사람이 읽기 쉽게 작성해야 한다.
• SQL 인젝션 - 코딩 가이드 규칙준수??
• 보안코딩 - 플랫폼에서 기본지원..하는게 많음??

장애

• 무엇보다도 최단 시간에 원인을 파악해야 한다.
• 각종 메트릭, 로그 등을 수집, 쉽고 빠르게 조회할 수 있어야 한다.

보안 관련 작업 사례 공유

• DB
  • MariaDB 암호화 (TDE - Transparent Data Encryption) : [RNJOB] [DCDC]
    • Date-at-Rest
    • 데이터 파일 유출 시 안전함
  • 데이터 암호화 : [Trailwalker]
  • 한계성
    • Key 파일 위치 분리 / 관리에 대한 방법을 고민할 필요가 있음
    • 도입 난이도가 높고 운영 등 고비용 발생
• Headless 워드프레스
  • GraphQL 을 API로 통신하도록 사용자 화면 분리 (Headless)
    • 워드프레스는 CFL분리 / 접근 시 Access 로 완전 보호
  • 공격 지점을 최소화하라.

서비스 패키지 구성안

• 예산 기준으로
  • 베이직 : ~ 2,000만
  • 어드밴스드 : ~ 1억
  • 커스텀
• 서비스 기준으로
  • CMS 일체형
    • DB 암호화
    • CFL 방화벽
  • Headless (F/B 분리형)
    • DB 암호화
    • CFL 방화벽
  • 운영유지
    • 웹 프로그램
    • 웹서버 관리

결론: 우리가 제공할 수 있는 서비스 및 코딩 원칙을 문서로 정리하자

• 우리가 지켜야 할 사항 - 개발 / 코딩 시 ‘체크리스트’
• 우리가 제공할수 있는 서비스 - 내부 / 외부 솔루션 모두 ‘등급별 / 항목별’

인프라 소유 유형에 따른 운영 방식 원칙

• 자체 호스팅 시 운영사에 가이드 제공
• 공용 호스팅 시 관련 서비스 이용유도

현실, 기타

• 운영유지 계약 시 관련한 내역을 명문화 할 필요가 있음
  • 계약사항에 따라 어떤 서비스를 제공할지 ‘서비스화’ 해야함
  • 계약사항 중 해당 항목이 없으면 실질적인 책임이 없다
• 하드웨어 관리는 실상 불가능하다.
  • 파트너사가 있어야 함
  • 현실적으로, 단독 호스팅 사용 고객은 서버 관리 업체가 존재하거나 팀이 존재함.
  • 가이드 제공시, 관리 업체가 설정 거부 또는 불가능이라 할 때, 서비스 제공 계약을 고려한다. (돈을 받는다)
• 작업 후 운영 배포 시
  • 테스트 시나리오 정의가 필요한데… 지금은 없다.
    • 외부 의존성 여부
    • 조건 별 통과를 위한 결과 pass 여부