[API 보안 인 액션]: Past-Forward 프로젝트와 더불어

[API Security In Action]을 읽고 알게된 새로운 지식과 더불어 진행했던 프로젝트를 예시로 이해한 것을 기록하는 포스팅입니다.

따라서, 해당 포스팅에 등장하는 예시들은 프로젝트에서의 경험을 기반으로 하는 것이 훨씬 많다는 점과 책을 읽으며 알게 된 지식에 대한 내용이 더 많다는 점을 참고해주시면 감사하겠습니다.

---

`Past-Forward`회고 웹 애플리케이션 개발에 `백엔드팀: 리더`, `PM팀: 팀원`으로 참여했습니다.

👤 앞선 말 & 책을 선택하게 된 계기

프로젝트를 시작하기 전, 저는 정말 개발 언어라고는 하나도 모르던 비전공 졸업생이었습니다.

* 정말 해본 거라곤 MySQL 조금과 마크업 언어인 HTML, CSS뿐이었어요. 그야 저는 사실 마케터 지망생이었거든요...ㅎ

도대체 당시에 무슨 생각을 했기에 아무것도 모르면서 백엔드팀에 합류해서 그것도 팀리더를 하겠다고 했는지...

기억나는 건 덜덜 떨면서 백엔드팀에 함께 하고 싶다고 체크하던 제 모습과 본격적인 설계 및 구현 전에 팀 내에서 회의해야 할 것들을 찾아보느라 하루종일 구글링 하던 날들 뿐이네요.

 

처음 API 명세서를 만들던 날부터 프로젝트의 마무리까지 가장 많이 접했던 단어가 `API`입니다.

처음 `RESTful API`라는 개념을 알게 되어 API에 대해 좀 더 알아보고 싶다고 생각했고, 우연찮게도 프로젝트 이후부터 수강 중인 부트캠프에서 해당 책을 구입해주어 접하게 되었습니다.

책 제목을 보고 제가 평소에 명확히 하고 싶던 지식과 더불어 부족한 점이 있다면 보완할 수 있을 것 같아 선택하게 되었습니다.

 

해당 책을 통해 API에 대해 제 안에서 명확한 정의가 되기를 바라며, API 설계 시 나는 보안에 대해 얼마나 고려했을지를 판단하는 시간을 가져보는 것도 좋겠다는 생각이 들어 글을 남깁니다.

 

더불어 또다른 개발자가 되고 싶은 비전공자들에게 많은 용기나 지식을 나눠줄 수 있기를 기대해봅니다.

---

📌 API 보안 인 액션: 근데 이제 프로젝트를 곁들인...

* API와 API 보안에 대한 지식 정리를 기반으로 프로젝트 경험을 녹여냅니다.

API(Application Programming Interface)
: 소프트웨어 시스템의 한 부분과 다른 부분 사이의 경계 역할, 사용자 대신 하나 이상의 클라이언트 요청을 처리

❓ API vs UI

• API: 다른 소프트웨어와 쉽게 상호작용 가능한 설계
  프로그램이 구문을 분석하고 조작하기 쉽게 규칙적 + 사용자 입장에서 보기 어려운 `원시 데이터 형태` 제공
• UI: 사용자가 `직접` 소프트웨어와 삭호작용 가능한 설계
  정보를 읽기 쉽고 상호작용하기 쉽도록 다양한 형태로 정보 제공

API 방식

RPC(Remote Procedure Call)

• 네트워크 연결을 통해 클라이언트가 호출할 수 있는 일련의 프로시저/함수 표시
• 로컬에서 제공되는 일반 프로시저 호출과 유사한 설계
• e.g.) 예다, XML, SOAP 등의 프레임워크

RMI(Remote Markup Invocation)

• 객체 지향 기술 사용
• 원격 객체의 메서드를 로컬인 것처럼 호출 가능
• CORBA, EJB => 프레임워크의 복잡성 문제로 사용 감소

EJB에서 JPA로: 스프링의 역사
2000년대 초반: JAVA 진영에는 EJB(Enterprise Java Bean) 존재
이는 Spring + JPA + Entity Bean + etc 가 모두 들어가 있는 파워 멋쟁이였습니다.
하지만 이렇게 많은 것이 한 데에 몰려 있으니 비싸고 복잡하고 어렵고 느리기까지 했죠.
그러니 화가 난 개발자 로드 존슨과 개빙킹이 개발자들을 구하기 위해 활동하기 시작합니다.
그렇게 나타난 것이 지금의 Spring, JPA입니다.

REST(REpresentational State Transfer)

• HTTP와 웹의 성공을 이끈 원칙에 대해 설명 -> API 설계를 위한 일련의 원칙으로 채택
• 클라이언트와 특정 API 간의 연결 감소 목적
  : `표준 메시지 형식`과 소수의 일반적인 작업만 강조
• API 탐색 - 하이퍼링크 사용 시, 시간이 지나 API가 발전되어도 클라이언트가 중단될 위험 감소
• 현 시점에서 `RESTful API`가 가장 많이 사용됨

ETC

• SQL 데이터베이스, GraphQL 프레임워크와 같은 대규모 데이터의 집합을 효율적으로 쿼리하거나 필터링하는 데에 주로 사용
• 쿼리 언어를 통해 클라이언트가 반환하는 데이터에 대한 통제 가능

---

 

API 보안

• Information Security(정보 보안) | 생성, 저장, 전송, 백업, 최종 파기의 전체 수명 주기 동안 정보 보호
  • 보안 목표 정의/위협 식별
  • 접근 통제 기술 - API 보호
  • 암호화 적용 - 정보 보안
• Network Security(네트워크 보안) | 네트워크를 통해 흐르는 데이터 보호와 네트워크 자체에 대한 비인가 접근 방지
  • 기본 인프라(방화벽, 로드 밸런서, 역방향 프록시)/인프라의 역할
  • 통신 프로토콜(API를 서로 주고 받는 데이터 보호 목적)
• Application Security(애플리케이션 보안) | 소프트웨어 시스템이 공격과 오용을 견딜 수 있도록 설계/구축되는 것을 보장
  • 안전한 코딩 기법
  • 일반적 소프트웨어 보안 취약점
  • API 접근 목적의 시스템/사용자 자격 증명 저장과 관리

* 외에도 다양한 보안 분야 존재, 이 여러 분야의 교차점에 있는 것이 `API 보안`

---

API에 대한 각각의 요청은 방화벽을 적어도 하나 이상 통과

각각의 제품에서 사용되는 기본 보안 메커니즘을 잘 이해하면 제품이 애플리케이션에 적합한지와 제품의 강점/한계를 정확하게 평가는 데에 도움이 됩니다.

방화벽

상대적으로 낮은 수준에서 네트워크 트래픽 검사

정상적이지 않은 트래픽을 차단하는 기능

ex) API 80 포트 및 443 포트에 대한 요청만 처리하는 경우, 방화벽은 다른 포트에 대한 모든 요청 차단

로드 밸런서

트래픽을 적절한 서비스로 라우팅

각각의 서버가 유휴 상태로 있거나 많은 요청으로 과부화되지 않도록 보장

역방향 프록시

애플리케이션 서버 앞에 배치

TSL/SSL 암호화 처리 및 요청에 대한 자격을 증명하는 등의 복잡한 작업 수행

클라이언트의 TSL 연결이 목적지 API 서버 앞에서 로드 밸런서/역방향 프록시에 의해 결정될 때 SSL 종료나 SSL 오프로딩 발생
프록시에서 백엔드 서버로 별도 연결
암호화되지 않고 평문 HTTP로 통신하거나 SSL 재암호화 과정을 통해 별도의 TSL 암호화 연결 가능

API 게이트웨이

서로 다른 API를 하나의 API인 것처럼 보이게 할 수 있는 특수한 역방향 프록시

클라이언트에게 제공되는 API를 단순화하기 위해 마이크로 서비스 아키텍쳐 내에서 주로 사용

웹 애플리케이션 방화벽

기존 방화벽보다 높은 수준에서 트래픽 검사

HTTP 웹 서비스에서 일반적으로 많이 발생하는 공격 탐지 및 차단

침입 탐지(방지) 시스템

내부 네트워크 내의 트래픽 모니터링

의심스러운 활동 패턴 감지 시, 경고 발생 혹은 능동적으로 차단 시도

API의 허술한 보안 방식으로 인해 정교하게 설계된 게이트웨이를 손상시키는 경우 O
허술하게 구성된 게이트웨이는 네트워크에 새로운 위험 야기 O

---

API 보안 요소

API는 호출자가 사용할 수 있는 일련의 작업을 정의하는 역할을 맡고 있습니다.

따라서, 사용자가 수행을 원하지 않는 작업은 API에서 제외하면 돼요.

그렇다면 `API 보안`은 왜 신경써야 할까?

1. 특정 수준의 권한

프로젝트에서 `특정 수준의 권한`을 가진 사용자만이 접근할 수 있는 기능이 꽤 있습니다.

예를 들어,

• 회원가입 후, 로그인 한 사용자만이 개인/팀 회고 내의 기능을 사용할 수 있다.
• 관리자 권한을 가진 사용자만이 공지사항에 글을 작성/수정/삭제할 수 있다.
• 회고 내의 댓글은 해당 댓글의 작성자만이 수정/삭제할 수 있다.
• 팀 회고의 리더만이 팀 회고를 수정/삭제할 수 있다.

와 같은 상황들이 존재합니다.

이는 이외의 사용자들이 어떠한 의도를 가지고 작업을 하는 것을 통제하기 위함입니다.

 

정리

• 특정 수준의 권한을 가진 사용자만이 동일한 권한을 요구하는 API에 접근 가능 = 이외의 사용자는 접근할 수 없도록 적절한 `접근 통제` 필요
  => 그렇지 않을 경우에 보안상 바람직하지 않은 행위를 할 수 있기 때문에 방지하는 것

2. API 조합 시, 안정성 문제

• 회원가입 시 이메일이 실제로 존재하는 이메일인지
• 팀 회고에 참여하는 사용자는 실제로 해당 팀에 속한 사용자인지

와 같이 개별 작업이 아니라 `전체 작업`을 고려해야 하는 경우가 더러 발생합니다.

3. API 구현으로 인한 보안 취약점

DoS공격으로 서버가 다운되는 경우가 있어 고려해야 할 사항입니다.

DoS(Denial of Service)
공격자가 사용 가능한 모든 메모리를 소모할 수 있는 매우 큰 입력을 전송하는 서비스 거부 공격
정상적인 사용자가 서비스에 접근하는 것을 방해하기 위해 사용
서비스에 네트워크 트래픽을 다량으로 보내 정상적 요청 처리를 방해하거나 네트워크 연결을 끊거나 버그를 통해 서버를 충돌시키기도 함

이와 같은 문제에 대해 잘 대처하기 위해서는 어떻게 해야할까요?

보안 구현에 적합한 방식

코드를 짜기 전에 보안 개발에 대해 고려해야 합니다.

개발/운영 단계에서 보안 결합이 드러날 때까지 기다려서 문제가 발생한 이후에 이를 해결하려면 많은 노동과 비용이 들게 됩니다.

그렇기 때문에 `완벽하게 안전한 시스템`이 없다는 생각으로 `API 설계`단계에서 미리 고려해야 합니다.

[API 설계 시, 보안에 대해 고려할 점]
1. 데이터, 자원, 물리적 장치 등 보호해야 할 `자산`
2. 계정 이름의 기밀성과 같은 중요한 `보안 목표`
3. 보안 목표를 달성하기 위해 사용 가능한 `메커니즘`
4. API가 동작하는 환경/환경 상에 존재하는 `위협`

---

중요한 부분인 만큼 고려사항에 대해 좀 더 자세히 알아볼 필요가 있겠네요.

자산

[자산의 종류]

• 정보: 고객 이름, 주소, 이메일, 데이터베이스 콘텐츠와 같은 정보
• 물리적 서버 & 장비: 데이터 센터, 하드웨어 등
• 자원: 운영체제, 소프트웨어의 취약점을 통해 하드웨어가 제공하는 자원
  => 누군가에게 가치 있는 시스템에 연결된 모든 것

보안 목표

자산을 보호하기 위해 보안이 실제로 무엇을 의미하는지 정의하는 데에 사용

비기능적 요구 사항(NFR, Non-Functional Requirment)로 간주될 수 있음

성능이나 안정성 목표와 같은 다른 NFR과 함께 고려될 수 있음

상황에 따라 바뀌기도 하고, 1가지로 명확하게 정의할 수 없어서 거의 모든 시스템에 적용되는 몇 가지 표준 보안 목표가 존재합니다.

[CIA 3요소]

• `기밀성(Confidentiality)`: 의도된 대상만 정보를 읽을 수 있도록 보장
  한 사용자가 타 사용자의 정보를 읽을 수 있으면 안 되겠죠
• `무결성(Integrity)`: 정보의 무단 생성/수정/파기 방지
  한 사용자가 타 사용자의 정보를 함부로 바꾸거나 탈퇴시키거나 자신의 것이 아닌데 계정을 생성하는 등의 상황이 발생할 수 없게!
• `가용성(Availability)`: API의 정상적인 사용자가 필요할 때 접근할 수 있고 차단하지 않도록 보장
  공격자만 차단해야지 정상적인 사용자까지 차단할 수는 없잖아요! 쓰도록 만든 건데!

[암호화]

보안 목표를 정확하게 만드는 접근 방식

보안 목표: 공격자와 시스템 간의 일종의 게임
공격자에게 다양한 권한 부여

- 게임 방법

• 공격자가 2개의 동일한 길이의 메시지 A와 B를 제출
• 시스템은 임의로 하나를 선택(50% 확률 게임)
• 키를 사용해 암호화
• 암호화 메시지를 받은 것이 A인지 B인지 추측하는 것이 어렵다면 시스템 승리

- 승리 조건

실제 공격자가 올바르게 추측할 확률이 50% 미만일 경우, `시스템 안전`하다 판단해 시스템 승리

 

[제약 조건]

보안 목표: 기존 기능 요구 사항에 대한 제약
시간이 지나며 제약 조건이 명확해짐에 따라 프로세스는 항상 반복되거나 개선됨
자산을 식별&&보안 목표 정의 후에는 이런 목표를 테스트 가능한 제약 조건으로 분류
제약 조건 구현 후, 테스트할 때 보호해야 할 신규 자산을 식별하게 되는 경우 O

- 확인 방법

• 2명(A, B)의 dummy 사용자 생성
• 각 dummy 계정에 dummy 회고를 생성
• A 사용자가 B 사용자의 정보/회고 등에 접근할 수 없는지 확인
• 로그인하지 않은 사용자가 타 사용자들의 정보/회고 등에 접근할 수 없는지 확인

+ 프로젝트의 `기능 명세서`에 추가된 내용이나 1차, 2차 배포 이후에 진행했던 `QA Test`

결국, `보안은 일회성 프로세스가 아니다!`

환경 및 위협 모델

API가 작동할 환경과 해당 환경에 존재할 잠재적 위협 고려

위협: 하나 이상의 자산과 관련해 보안 목표를 위반할 수 있는 모든 방법
= API의 보안 목표를 위반하는 이벤트/상황의 집합
위협 모델: API와 관련 있다고 간주하는 위협의 집합
위협 모델링: 소프르퉤어 시스템에 대한 위협을 체계적으로 식별해 기록/추적/완화할 수 있도록 하는 프로세스

DB에 저희가 받은 고객의 회원가입 정보 등이 저장됩니다.

이런 DB에 공격자가 접근해 이를 도용하게 되는 상황 등이 발생하면 곤란하겠죠.(:기밀성 위협 행위)

 

아까 잠깐 언급했지만, 다양한 상황에서 위협은 발생합니다.

그렇기 때문에 우리는 `현실적인 위협`을 고려해야만 어디에 집중할지를 결정하고 방어하기 위한 방법을 탐색할 수 있어요.

 

- 위협 모델링의 일반적인 프로세스

• 시스템 다이어그램 그리기: API의 주요 논리적 모델
• 시스템 부분 사이의 신뢰 경계 식별
• 화살표를 그려 데이터 흐름 표시
• 시스템 각 구성 요소/데이터 흐름 검사 - 각 경우에 보안 목표를 저해할 수 있는 위협 식별
  : `신뢰 경계를 넘는 흐름`에 특히 주의!
• 위협을 추적/관리할 수 있도록 기록