-
[OAuth 2.0 API 보안] API 보안 설계보안/인증, 인가 2022. 5. 9. 18:50
OAuth 2.0
1. 데이터 유출의 3가지 원인
연결성
- 최근 기업체들에선 많은 API나 시스템을 연동한다.
- 여기에는 보안적 결함이 존재하는 레거시 시스템들도 포함된다.
확장성
- 최근의 시스템들은 확장의 용이성을 고려하여 설계, 제작된다.
- 새롭게 추가되는 소스코드들의 기능은 브라우저와 같은 곳에서 보안 요소의 우회를 발생시킬 수 있다.
복잡성
- 복잡성으로 인해 파악되지 못한 취약점이 다수 존재할 수 있다.
- 복잡성은 유지보수의 난이도 상승으로 연결되어 수정하기 힘든 취약점이 다수 존재할 수 있다.
2. API 설계에서 고려할 점
사용자 경험
- 강한 보안 요소를 적용시키기 위해 사용자의 편의성을 과도하게 침범하면 안 된다.
- 나쁜 사례 : 과도한 비밀번호 조건
- 좋은 사례 : FaceID
성능과 비용
- 접근 키가 필요한 API
- 키를 탈취 당할 경우 피해 최소화 전략 → 키의 유효 시간을 줄이기
- 좋은 사례 : 전송 계층에서의 TLS 적용
- 성능의 고려
- 암호화를 적용한 HTTPS는 HTTP에 비해 더 많은 자원을 소모한다.
- 절충안 : 암호화가 필요한 외부 통신은 HTTPS를, 내부 통신은 HTTP를 사용한다.
- 단, 이 경우 내부의 보안을 강화해야 할 수 있다.
- HW 장치 사용 : TLS와 같은 암/복호화 알고리즘을 HW를 통해 수행한다.
- 취약 지점
- 일반적으로 가장 취약한 지점은 주로 통신 채널이나 애플리케이션이다.
- 위협 모델링을 통해 식별해야 한다.
- 심층 방어
- 여러 계층의 보안 요소를 적용하여 계층적 방어를 구현한다.
- 물리적 보안, 네트워크의 방어, 애플리케이션의 보안 설정, 내부 시스템간 보호 등이 있다.
- 심층 방어는 내부자 공격에 대해서도 방어선을 제공한다.
- 내부자 공격
- 가장 효과적이고 해결하기 힘든 문제이다.
- 사회공학적, 물리적으로 접근한다.
- 은닉
- 공격자로부터 방어하기 위한 전략으로 존재 자체를 숨기는 은닉을 시도할 수 있다.
- 키 볼트, 보안 프로토콜 설계 자체를 숨기는 것이다.
- 다만 단독으로 쓰여서는 위험하다. 심층 방어 전략의 한 계층으로써 사용한다.
3. 실제 설계에서는?
최소 권한
- 작업 수행을 위한 최소의 권한 만을 부여한다.
- 실제 상황에서 피해를 제한하는 역할을 한다.
- 정보의 접근에 대해서 “누가, 언제, 무엇을” 과 같은 접근을 기록한다.
고장 안전 디폴트 원리
- 허가되지 않은 모든 접근은 거부한다.
- 시스템 장애나 에러가 발생하더라도 접근이 불가능하게 해야 한다.
메커니즘과 비용
- 설계를 단순화하여 복잡성을 줄인다.
완전 중개
- 사용자 인증과 같이 권한 검사가 이루어지면 이를 캐싱하고 재사용 할 수 있다.
- 이는 성능 향상으로 연결되지만 반대로 공격자가 그 권한을 재사용할 수 있다.
- 따라서 권한의 변경이 발생하면 시스템이나 캐시에 즉시 반영해야한다.
개방형 설계
- 암호화는 반대의 개념이지만 암호화나 은닉에 의존해서는 안된다는 개념이다.
권한 분리
- 최소 권한과 연결되며 네트워크 분리 등을 통해 시스템을 설계한다.
- 다른 시스템으로의 접근법을 제공하고 접근 과정에 승인 절차를 추가한다.
최소 공통 메커니즘
- 시스템 간의 공유되는 요소가 최소화 될 수록 피해 발생 시 그 정도가 최소화된다.
- 시스템 배치 장소가 공유될 경우 하나의 서비스 공격이 성공하면 다른 서비스도 위험해질 수 있다.
심리적 수용
- 보안 요소가 내부 자원의 접근을 침해해서는 안 된다.
- 사용자의 편리함이 곧 보안 요소의 쉬운 사용으로 연결된다.
4. 보안 요소
기밀성, 무결성, 가용성과 이를 만족시키기 위한 4개의 역할이 주어진다.
보안 제어 역할
- 인증 : 대상이 본인 그 자체라는 것을 식별한다.
- 인가 : 인증된 대상의 작업 수행을 검증한다.
- 부인 방지 : 사용자 본인임을 부인할 수 없고 위조할 수 없도록 한다. 무결성 방지를 위한 서명을 사용한다.
- 감사 : 합법적 접근, 불법적 접근과 같은 기록을 추적하고 위협을 식별할 수 있도록 한다.
'보안 > 인증, 인가' 카테고리의 다른 글
[OAuth 2.0 API 보안] OpenID 커넥트 (OIDC) (0) 2022.06.07 [OAuth 2.0 API 보안] API 게이트웨이를 이용한 에지 보안 (0) 2022.06.02 [OAuth 2.0 API 보안] OAuth 2.0 (0) 2022.05.19 [OAuth 2.0 API 보안] TLS를 통한 API 보안 (0) 2022.05.19 [OAuth] Social Auth REST API : URI MISS MATCH (1) 2021.12.26