하드 링크 (Hard Link) 와 심볼릭 링크 (Symbolic Link) 는 운영체제 파일시스템을 이해하는데 기초적인 개념이다.

아마 윈도우를 많이 사용한다면, 원본 - 바로 가기 개념이 떠오를 수 있지만 다소 차이가 있다.

 

  • Hard Link
    • 원본 파일과 동일한 inode 를 가지며 원본 파일이 삭제되더라도 링크 파일을 여전히 사용 가능하다
    • ln [Source] [Target] 명령어로 생성 가능
    • 위치 정보를 가지고 있는 이름을 여러 개 생성하는 개념이다. 그렇기 때문에 한 파일을 지워도 하드에서 해당 위치를 찾아갈 수 있다
  • Symbolic Link
    • 원본 파일의 이름을 가리키는 링크로 원본 파일이 삭제되면 사용 불가능하다
    • 전혀 다른 파일이라도 가리키는 원본 파일 이름이 같으면 계속 사용 가능하다
    • ln -s [Source] [Target] 명령어로 생성 가능. Source 를 가리키는 심볼릭 링크 Target 을 만든다
    • Source 파일을 수정하면 심볼릭 링크인 Target 파일도 수정된다
      • Target 파일을 수정해도 Source 파일이 같이 수정된다
    • 위치 정보를 갖고 있는 파일명을 또 다른 이름으로 가리키는 포인터의 개념이다
      • 하드링크는 한 위치 정보를 또 다른 이름으로 가리키는 개념

 

특히 리눅스 환경에서는 개발 환경 구성 시, 심볼릭 링크를 사용해서 파일 경로를 간편하게 관리하기도 한다

(루트 디렉토리 내에 심볼릭 링크를 구성해서 마운트한 파일 시스템을 연결시킨다던지)

 

잘 알아두면 유용하게 사용할 수 있다. :)

 

 

웹 서버는 Stateless 프로토콜인 HTTP 를 사용하기 때문에 웹사이트에서 인증을 관리하기 위한 방안이 필요하다.

로그인을 한 유저들에 대해 권한이 필요한 매 요청마다 재로그인을 시킬수는 없는 일이다.

그렇기 때문에 웹사이트는 일반적으로 유저의 접속 정보를 관리하기 위한 몇가지 방안을 사용한다.

 

1. Session 기반 인증

세션 기반인증을 위해 Session 과 Cookie 가 사용된다. 다음 Flow 로 인증 절차가 진행된다.

 

 - 유저가 로그인을 하고 세션이 서버 메모리 상에 저장된다. 이 때 세션을 식별하기 위한 Session Id 를 기준으로 정보를 저장한다.

 - 브라우저에 쿠키로 Session Id 가 저장된다.

 - 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request 에 Session Id 를 쿠키에 담아 전송한다.

 - 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id 를 비교하여 Verification 을 수행한다.

 

Session 기반 인증은 다음과 같은 장단점을 갖는다.

 

+ 세션 기반 인증 방식은 구현이 상당히 명확하다는 장점이 있다. 또한 실제 서버에서 로그인 상태 확인이 굉장히 유용하다.

+ 상대적으로 안전하다. 서버측에서 관리하기 때문에 클라이언트 변조에 영향받거나 데이터의 Stale (손상) 우려가 없다.

- 유저들의 세션에 대한 정보를 서버 메모리에 들고 있게 된다는 부담이 있다.

- 서버 메모리에 세션 정보가 저장되기 때문에 Scale Out / Scale In 이 부담이 될 수 있으며, 결국에는 유저 상태에 무관하게 동작할 수 있도록 Data-Driven 아키텍처가 요구된다.

- 멀티 디바이스 환경에서 로그인 시 신경써줘야할 부분들이 생긴다. 

 

2. Token 기반 인증

Token 기반 인증의 방법으로 많은 웹 서버들은 JWT(JSON Web Token) 을 사용한다.

Token 기반 인증 방식과 Session 기반 인증 방식의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않는다는 점이다.

Flow 는 다음과 같다.

 

 - 유저가 로그인을 하고 서버에 세션을 이용해서 정보를 기록하는대신, Token 을 발급한다.

 - 클라이언트는 발급된 Token 을 저장한다 (일반적으로 local storage 에 저장한다.)

 - 클라이언트는 요청 시 저장된 Token 을 Header 에 포함시켜 보낸다. 

 - 서버는 매 요청시 클라이언트로부터 전달받은 Header 의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가한다.

 

Flow 에서 차이를 확인할 수 있듯, Session 기반 서버가 서버측에 정보를 기록하는 반면, Token 기반 인증은 Token 에 대한 Verification 만 수행할 뿐 저장은 클라이언트에서 수행한다.

Token 기반 인증은 다음과 같은 장단점을 갖는다.

 

+ 클라이언트에 저장되기 때문에 서버의 메모리에 부담이 되지않으며 Scale 에 있어 대비책을 고려할 필요가 없다

+ 멀티 디바이스 환경에 대한 부담이 없다.

- 상대적으로 Stale (손상) 의 위험이 크다.

- 결국 구현을 하다보면 서버측에 token blacklist 를 관리하게 될 가능성이 있고 그렇게 되면 서버측 메모리의 소모가 발생하게 된다

- Token 은 일반적으로 Session ID 보다 길다.

- XSS 공격에 취약할 수 있어 가능한 민감한 정보는 포함시키지 않을 필요가 있다.

 

최근에는 Scaling 이슈와 멀티 디바이스 이슈로 Token 방식이 좀 더 핫한 느낌이지만, Session 방식도 여전히 많이 쓰인다.

두 방식 모두 장단점이 있기 때문에 적합한 구조를 선택하는 것이 좋겠다.

 

 

사실 보안쪽에 문외한이다보니 처음 배웠을 때 아주 생소한 개념이었다.

하지만 백엔드에 종사하다보니 얼마나 중요한지 알게되었고, 다시 한번 정리를 해보았다.

 

 

사실 Threat Modeling 이라는 단어는 비단 IT에서만 쓰는 용어는 아니고, 위험 요소에 대해 평가해보는 전반에 걸쳐 사용되는 언어이다.

하지만 IT 용어로써 Threat Modeling 이란 MS 사에서 대중화한 개념으로 잠재적인 위협을 모델링하고 이를 완화할 수 있도록 할 수 있는 프로세스를 말한다.

가령, 구조적 취약점이나 방화벽 등 보안장치의 부재와 같은 위협들이 모델링의 대상이 될 수 있다. 

위협 모델링의 목적은 시스템의 특성과 방어 시스템을 고려했을 때 어떤 부분에 있어서 방어가 필요하고 보안상 취약할 수 있는지 가능성을 찾는 것으로 특히 특정한 위협포인트에 대해 미지수일 경우 가능한 취약점을 찾는 것이 되겠다.

또한 공격자의 입장을 시뮬레이션해보고 공격 측면(Attack Surfaces) 을 찾아내는 일이 포함된다.

 

그렇기 때문에 Threat Modeling 이 가능하려면 먼저 다음을 알아야 한다.

    - 시스템의 구조 (Architecture)

    - 시스템의 보안 상태

    - 보호해야하는 가치있는(Valueable) 자산이 무엇인지

    - 가능한 공격자 후보군

위협요소 탐지를 위한 Threat Modeling 방법론으로 주로 언급되는 4가지를 정리해본다.

 

  1. STRIDE : 다음의 머릿글자만 딴 약어이며 다음 6가지에 대한 위협을 측정한다.

Spoofing(공격자가 권한이 있는 사용자인척 위장하는 공격 방식)

Tampering(목적을 위해 시스템 내부 데이터를 악의적 수정해서 공격)

Repudiation(악의적 활동 이후에 해당 활동에 대해 부인하는 것)

Information Disclosure(보호된 정보에 대한 노출)

Denial of Service(서비스에 대한 믿을 수 있는 접근을 바탕으로 한 공격. 분산해서 공격하는 것을 DDoS라 한다.)

 

  2. DREAD : 다음의 머릿글자만 딴 약어이다. MS 에서는 현재 제공되고 있지 않는 것으로 보이지만 OpenStack 등에서는 여전히 쓰이고 있는 방법이라 한다.

Damage Potential(취약점이 노출되었을 경우 발생 가능한 피해량)

Reproducibility(재공격 당하기 쉬운 정도)

Exploitability(공격을 하기 위해 필요한 공수)

Affected Users(위협이 얼마나 많은 유저에게 노출되는지)

Discoverability(얼마나 위협을 탐지하기 쉬운지)

위의 수치의 평균을 Risk 로 정의한다.

 

  3. P.A.S.T.A : Process for Attack Simulation and Threat Analysis 의 약어로 비즈니스 컨텐츠 및 기술 요구 사항에 따라 7단계로 프로세스가 구성된다. 방법의 목적은 직접 위협 요소를 검증하고 위협 요소들에 대해 점수를 부여해서 분석하고 완화시키기 위한 방법을 개발자에게 제시하는 것이다.

 

  4. VAST : Visual, Agile, and Simple Threat modeling 의 약어로 인프라 및 시스템 전체에 대한 모델링이 필요하며 Agile 프로세스에 위협 모델링 정보를 Visualize 할 수 있는 부분을 포함한다. 그렇기 때문에 전문적 지식없이 간단하게 진행되며 그를 지원해줄 수 있는 어플리케이션이 요구된다.

 

개발자 입장에서는 놓치기 쉬운 측면이고 정책적인 부분 또한 강하지만 OWASP(Open Web Application Security Project) 에서도 강조하고 있는 보안 위험을 대하는 구조화된 접근 방식이다.

다음을 참고하자 - (https://www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet)

 

위협 모델링은 운영이 편리하고 취약점을 공유할 수 있는 부분이 큰 장점으로, 그에 따라 위험을 공유하고 같이 협력해서 대처할 수 있다는 큰 장점이 있다.

하지만 중요함에도 이를 적절하고 의미있게 실행하기는 쉽지 않은데, Best Practice 가 많지 않고 향후 위협 가능성보다는 현재의 위협에 초점을 두고 취약점 위주의 분석이 주가 되기 때문이다.

 

개발자 뿐만 아니라 시스템 전반에 걸친 모두의 협력이 지속적으로 이루어져야 가능한 부분이 아닐까 생각이 든다.

 

+ Recent posts