오늘날의 보안

안타깝게도 소프트웨어 작성 초기부터 보안을 신중하게 고려하는건 현재 일반적인 관행이 아니다. 기술을 익히는 초기 단계부터 이런 관행의 문제점이 잘 드러나지 않는것은 문제가 있다.

소프트웨어 시스템을 다룰때는 비 기능적 측면을 고려해야 한다

스프링 시큐리티

스프링 시큐리티는 스프링 어플리케이션에서 보안을 구현할때 가장 우선적인 선택이다. 인증 권한 부여 및 일반적인 공격에 대한 방어를 구현하는 세부적인 맞춤 구성 방법을 제공한다.

스프링 시큐리티를 이용한다 해도 어플리케이션이 자동으로 보호되는것은 아니다.

현재 소프트웨어 시스템은 GDPR(일반 데이터 보호 규정) 요구 사항을 고려할 때 상당 부분이 민감한 정보일 수 있는 대량의 데이터를 관리한다.

전화번호, 이메일주소, 식별 번호 와 신용 카드 정보등이 있다.

인증은 어플리케이션이 사용자를 식별하는 방법이다. 권한은 사용자가 무엇을 할 수 있는지 허용하는 방법이다.

일반 적인 보안 취약성은 다음과 같다

인증 취약성
세션 고정
XSS
CSRF
주입
기밀 데이터 노출
메서드 접근 제어
취약성이 발견된 의존성 이용

어떤 사용자나 존재가 앱을 이용하려 할때 ID를 확인해야 한다.

권한 부여는 인증된 호출자가 특정 기능과 데이터에 대한 권리가 있는지 확인하는 프로세스이다. 인증 취약성이 있다는 것은 악의적인 데이터 접근, 기능 악용의 우려가 있다는 뜻이다.

생성된 세션을 재이용해 유용한 사용자를 가정한다 세션 ID를 URL에 넣는 경우 악성 링크를 클릭하도록 유인하거나.

외래 양식을 이용하도록 할수 있다.

서버에 노출된 웹 서비스로 클라이언트 쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 한다. 원치 않는 외래 스크립트의 실행을 방지하기 위해, 이용하기 전과 저장하기 전에 적절이 소독하는 과정이 필요하다.

특정 서버의 작업을 호출하는 URL을 추출하여 어플리케이션 외부에서 재사용한다. 서버가 요청의 출처를 확인하지 않으면 어떠한 곳에서도 무분별하게 요청이 실행될 수 있다,

기능적 요구사항과 비 기능적 요구사항에 따라 스프링 시큐리티의 구성을 알맞게 적용하여야한다.

일체형 어플리케이션의 시스템의 경우, 백엔드와 프론트엔드의 직접적인 분리가 없다. 일반적으로 이러한 종류는 어플리케이션이 각 요청을 수신하지 않고, 서블릿 흐름을 통한다.

세션이 있는한 CSRF 가능성을 고려해야하며, 세션에 저장하는 정보도 고려해야한다. CSRF를 방지하는 가장 간단한 방법은 CSRF방지 토큰을 이용하는 것이다.

최근에는 분리하도록 선택하는 경우가 많다. 이런경우 일반적으로 서버쪽 세션을 줄이고 클라이언트 세션으로 대체하는것이 좋다.

보안의 관점에서 CSRF,CORS구성은 조금더 복잡해지고, 모바일 어플리케이션은 출처를 확인할 수 조차 없다. 엔드포인트 인증에 Http basic을 이용하는 방법은 가장 간단하지만 바람직하지 않다

권한 부여서버와 리소스 서버라는 두가지의 별도의 엔티티를 정의한다.

권한 부여 서버는 사용자에게 권한을 부여하고, 토큰을 제공한다. 이 기능을 구현하는 것은 리소스 서버라 불리는 백엔드 서버에서 처리한다.

1. 사용자는 백엔드의 리소스를 호출해야 한다.
2. 백엔드 서버는 권한 부여 서버를 호출하여 토큰을 얻는다.
3. 자격 증명과 갱신 토큰이 올바르면 권한 부여서버가 액세스 토큰을 클라이언트로 반환한다.
4. 리소스 서버에 대한 요청 헤더는 액세스 토큰을 이용한다.

호출자를 인증하고 권한을 부여하는 시점에, 교환되는 메시지를 변경할수 없게 하는 요구사항이 생길것이다. 그중 헤더값을 이용하는 방법, 암호화 서명, 아이피 주소로 검증하는 방법등 여러가지 방법은 이후 소개될 예정이다.

Last updated 10 months ago