개발놀이터

인증과 인가 본문

CS 지식/보안

인증과 인가

마늘냄새폴폴 2023. 5. 4. 20:17

평소에 인증과 인가에 대해서 자세히 알고있지는 않았습니다. 사실 인가가 뭔지도 잘 몰랐습니다. 이참에 공부를 해야겠다고 생각이 들더군요. 

 

때문에 이번 GPT에게 물어본 내용은 인증과 인가입니다. 거기에 제가 알고있던 부분을 첨가해서 포스팅 작성해보도록 하겠습니다. 

 

※ GPT야 이것좀 알려줘 카테고리는 원래 제가 작성하는 주제 (자바, 스프링, CS, 알고리즘) 와 다른 하지만 평소에 궁금했던 내용을 작성합니다. GPT가 답변한 내용은 ~이다 체로, 제가 작성한 부분은 ~습니다 체로 작성됩니다. 

 

인증과 인가

포스팅을 시작하기 전에 인증과 인가에 대한 정의를 먼저 말씀드리고 가야겠군요. 

 

  • 인증 : 말그대로 신뢰할 수 있는 사용자라고 인증하는 것
  • 인가 : 사용자가 할 수 있는 행위를 제한하는 것

 

인증과 인가에 대한 인터세 세상 보안의 중요성

인증과 인가가 중요한 이유는 다음과 같다.

  • 민감한 데이터를 보호해야하기 위해 : 많은 온라인 서비스나 애플리케이션은 개인정보다 재정적인 데이터와 같이 민감한 데이터를 저장하고 있다. 적절한 인증과 인가는 오직 인가된 유저들만이 데이터에 접근할 수 있도록 보장하는 것을 도와주면서 유저의 프라이버시를 위협하는 위험을 줄여준다. 
  • 인가된 접근을 보호하기위해 : 적절한 인증과 인가가 없으면 누구나 온라인 서비스나 애플리케이션에 접근할 수 있고 이는 공격자나 악성 코드들의 접근을 허용할 수 있다. Multi-Factor Authenticaiton (MFA) 이나유저의 역할에 기반에 접근을 통제하는 것과 같은 강력한 인증과 인가를 구현함으로써 조직은 비인가된 접근을 막을 수 있고 보안 사고의 위험을 줄여줄 수 있다. 
  • 규정 준수의 필요 : 많은 산업과 나라들은 민감한 데이터를 보호하고 접근이 적절히 컨트롤되는 것을 보호하는 것에 대한 일반적인 필요성을 가지고 있다. 이러한 요규들의 규정을 준수하는 것은 종종 강력한 인증과 인가를 구현하는 것을 포함한다. 그리고 이러한 규정 준수를 실패하게 되면 재정적인 패널티를 얻거나, 불법적인 행동을 하거나, 평판이 떨어지는 결과를 야기한다. 
  • 신뢰를 유지하기 위해 : 적절한 인증과 인가를 구현하지 않은 온라인 서비스나 애플리케이션은 다양한 공격에 취약하고 이는 유저나 고객들의 신뢰에 악영향을 미칠 수 있다. 강력한 통제를 구현함으로써 회사는 보안에 대한 그들의 약속을 입증할 수 있고 그들의 유저나 고개들에 대한 신뢰를 구축할 수 있다. 

 

인증과 인가를 구현하는 방법에는 다양한 방법이 있습니다. 인증을 구현하는 대표적인 방법으로는 세션과 JWT 인증 방식이 있고 인가를 구현하는 대표적인 방법으로는 Roll-based access control (RBAC), Attribute-based access control (ABAC), Mandatory access control (MAC) 가 있습니다. 

 

우리는 그중 먼저 인증을 구현하는 방법에 대해서 알아봅니다. 

 

유저 인증을 구현하기 위한 최적의 방법

유저 인증을 구현하기 위한 방법에는 기본적으로 세션을 사용하는 방법과 JWT 인증을 이용하는 방법이 있습니다. 세션을 이용하는 방법은 서버에 특정한 값을 세션으로 저장해 두고 필요할 때마다 꺼내와서 유저를 인증하는 방법입니다. 

 

기본적으로 세션을 그냥 쓰지는 않고 Redis라는 데이터베이스와 같이 사용하는 것이 일반적입니다. 이렇게 Redis + Sesion으로 구현하면 구현하기는 간단하지만 stateful 프로토콜로 동작하는 Redis + Session의 경우 사용자가 몇천만, 혹은 몇억명이 되는 경우 계속해서 데이터베이스에 데이터를 보내야하기 때문에 서버에 무리가 갈 수 있습니다. 

 

때문에 회원수가 엄청나게 많거나 MSA를 채택한 서비스에선 JWT 인증을 사용하는 것이 바람직할 수 있습니다. 하지만 JWT 인증 같은 경우는 보안상 취약한 이슈가 있기 때문에 이를 커버해줘야만 합니다. 

 

JWT 인증의 보안 이슈

  1. JWT 헤더에 알고리즘을 none으로 만들어서 하는 공격에 대한 대비를 해야합니다. 가끔 알고리즘을 SHA가 아닌 none으로 해도 인증이 되는 경우가 있기 때문에 조심해야 합니다. 
  2. JWT는 디코딩이 매우 쉽기 때문에 중요한 정보를 JWT에 넣으면 안됩니다. 
  3. JWT를 인증하기 위해 시크릿키를 적어 넣어야하는데 시크릿키를 대충 적어서 만들면 무차별 대입 공격에 취약하기 때문에 시크릿키가 털리게되면 인증을 마음대로 할 수 있어서 매우 조심해야 합니다. 
  4. 만약 JWT가 탈취당했을 경우 문제가 발생하는데 사실 이는 개발자 책임이 아니긴 합니다. 만약 카드를 분실하면 카드를 분실한 사람이 책임이 있기 때문입니다. 하지만 카드의 경우 정지를 해달라고 요청할 수 있지만 JWT의 경우 JWT를 정지하거나 회수하는 것이 구조적으로 불가능합니다.

1, 2, 3번은 개발자가 적당히 조심하면 되는 부분이지만 4번의 경우는 JWT가 가지고 있는 취약한 부분중에 하나입니다. 이러한 문제가 발생했을 때를 대비한 몇가지 솔루션이 있습니다. 

 

JWT를 잘 뺏기지 않도록 특정한 저장소에 저장해둔다거나 (HttpOnly cookie), JWT 블랙리스트를 만들어서 JWT가 올때마다 블랙리스트랑 검사해야 한다거나 (하지만 이렇게 하면 session과 큰 차이가 없습니다.), 유효기간을 짧게 설정한다거나 (ex. 5분) 하는 방법이 있습니다. 

 

하지만 개인적으로 JWT의 유효기간을 짧게 설정한 사이트를 이용해봤는데 (OKKY ver.2 초창기) 들어갈때마다 로그인이 풀려서 귀찮은걸 넘어서 커뮤니티를 이용하고 있다가도 로그인이 풀려버려서 작성하고 있던 게시글 혹은 댓글이 다 날아가버리는 그지같은 상황이 속출했습니다.

 

이러한 불편때문에 사람들이 호소하자 서버장은 다시 JWT가 아닌 쿠키 (세션) 방식으로 바꾸는 해프닝이 발생했습니다. 이렇게 자주 풀려버리는 문제 때문에 refresh token과 access token을 발금해서 언제든지 재발급할 수 있게 마련하는 방법도 있습니다. 

 

 

인가를 구현하는 여러가지 방법

인가를 구현하는 방법에는 앞서 설명했다시피 Roll-based access control (RBAC), Attribute-based access control (ABAC), Mandatory access control (MAC)가 있습니다. 이제 각각에 대해 설명해보고 장점과 단점에 대해서 알아보도록 하죠. 

 

RBAC

Roll-based access control 줄여서 RBAC는 접근할 수 있는 컨텐츠를 역할에 기반하여 접근을 통제하는 방법이다. 유저들은 할당된 다양한 역할이 있고 각각의 역할은 역할이 접근을 허용하는 유저들의 자원이나 액션의 접근을 결정하는 일련의 허가이다. 

 

이러한 허가들은 관리자에의해 결정되고 역할들은 그들의 일의 기능이나 책임에 근거해 유저에게 할당된다. RBAC는 관리자 입장에서 간단하고 확장하기 쉬운 접근 통제 모델이다. RBAC는 주로 엔터프라이즈 환경에서, 예를 들어 이커머스같은 곳에서 사용자, 판매자, 관리자와 같은 방식으로 접근을 제어하는 것으로 많이 사용된다. 

 

RBAC의 장점

  • RBAC는 관리자 입장에서 간단하고 쉽다. 그리고 이런 간단함은 다른 모델에 비해 더 효율적이고 비용적인 측면에서 값 싸게 이용할 수 있다. 
  • RBAC는 위험성을 줄일 수 있다. 그들의 일을 행하기 위해 필요한 자원을 접근할 때 유저들의 역할을 가지고 확신할 수 있기 때문에 보안상 이점을 가지고 있다. 
  • RBAC는 크고 복잡한 시스템에서 접근의 통제를 관리하는데 더 쉽다. 그 이유는 역할이 일의 기능과 일의 책임에 근거해 할당되기 때문이다. 

RBAC의 단점

  • RBAC는 그들의 일의 기능과 책임에 근거해 역할이 할당되기 때문에 그들의 역할을 변경하거나 업데이트 하기가 힘들다. 
  • RBAC는 유저들이 자원에 걸쳐 세분화된 컨트롤이 가능한 상황에서 효과적이지 않을 수 있다. 혹운 접근 통제 정책이 복잡해진다. 

 

ABAC

Attribute-based access control 줄여서 ABAC는 유저, 자원 혹은 환경과 연관된 속성에 근거해 접근을 정의하는 접근 통제 모델이다. 이 모델에서 접근 통제 정책은 사용자의 속성 (ex. 부서) 이나 자원의 속성 (ex. 민감한 자원) 그리고 환경적인 속성 (ex. 날짜)에 근거해 정의된다.

 

이러한 접근 통제 방식은 속성을 평가하는 정책에 의해 만들어지고 접근을 허락해야 하는지 혹은 통제해야 하는지를 결정한다. ABAC는 복잡한 정책들을 구현하기위해 사용될 수 있는 유연하고 역동적인 접근 통제 모델이다. 

 

ABAC의 장점

  • ABAC는 RBAC에 비해 접근을 통제하기 더 유연하고 역동적인 접근 방법을 제공한다. 접근 통제 정책이 유저의 속성이나 자원의 속성, 환경의 속성과 같이 다양한 속성에 기반할 수 있기 때문이다. 
  • ABAC는 유저들이 자원에 걸친 세분화된 컨트롤을 필요로하는 상황이나 접근 제어 정책이 복잡한 상황에서 더 효율적일 수 있다. 
  • ABAC는 접근 통제 정책이 단지 유저의 역할이나 일의 기능보다 더 다양한 것에 기반하고 있는 것을 보장함으로써 다른 모델에 비해 더 보안상 이점이 있다. 

 

ABAC의 단점

  • ABAC는 RBAC보다 관리자 입장에서 더 관리하기 복잡하고 어렵다. 이는 접근 통제 정책이 다양한 속성에 기반하고 있기 때문이다. 
  • ABAC는 다른 모델에 비해 더 자원이 집중되어 있다. 이는 접근 제어 정책이 유저들과 연관된 속성을 평가하는 정책에 의해 만들어지기 때문이다. 
  • ABAC는 다른 모델에 비해 사용하는 유저에게 덜 직관적이다. 왜냐하면 접근 제어 정책이 특정한 역할이나 일의 기능에 기반하고 있지 않기 때문이다. 

 

MAC

Mandatory access control 줄여서 MAC는 시스템 안에서 객체 혹은 주제가 할당되는 일련의 규칙이나 라벨을 근거해 접근을 통제하는 모델이다. 

 

이 모델에서 자원에 접근하는 것은 일련의 보안 수준에 근거해 제한되고 유저들은 그들이 접근할 수 있는 수준을 결정하는 보안상 청결함이 할당된다.

 

보안 수준의 청결함은 관리자에 의해 결정되고 접근 통제 모델은 시스템안에서 결정된 규칙에 근거한다. MAC는 보통 정부의 보안 관련 컨텐츠나 군대에서 사용된다. 이곳은 민감한 정보를 다루는 기관들이기 때문에 인가 정책을 고수해야 한다. 

 

MAC의 장점

  • MAC는 라벨이나 규칙에 기반한 강제적으로 제한된 접근 제어 정책을 가짐으로써 매우 강력한 보안을 제공한다. 
  • MAC는 정부나 군대와 같이 내부자에 의한 공격에 취약한 경우 효과적일 수 있다. 
  • MAC는 높은 수준의 민감한 정보에 대한 무결성을 자랑한다. 

 

MAC의 단점

  • MAC는 관리자 입장에서 관리하기가 복잡하고 어려울 수 있는데 그 이유는 접근 통제 정책이 정의가 필요하거나 관리가 필요한 라벨이나 규칙에 의해 기반하기 때문이다. 
  • MAC는 접근 통제에 대한 요구에 의해 정책이 변결될 때 적철하지 못하다. 
  • MAC는 모든 환경에서 부적절하다. 그 이유는 자원이 밀집되어 있고 시스템 성능에 영향을 미치기 때문이다. 

 

흔히 일어날 수 있는 보안상 취약점

약한 수준의 보안 패스워드

인증 시스템에서 가장 흔한 취약점 중 하나는 바로 쉽게 추측 가능한 패스워드를 사용하는 것이다. 이렇게 취약한 패스워드는 공격자로 하여금 유저의 패스워드를 추측함으로써 시스템에 쉽게 접근할 수 있게끔 한다. 이러한 위험을 줄이기 위해서는 강력한 패스워드 정책이 필요하고 유저들은 추측하기 어려운 복잡한 패스워드를 사용하는 것이 필요하다. 

 

부족한 제 3자 인증

인증에서 또 다른 취약점은 바로 Multi-Factor Authentication (MFA)의 부족이다. MFA는 패스워드 말고 추가적인 보안 계층인데 예를 들어 지문을 인증하거나 토큰을 가지고 유저의 신원을 입증하는 것이다. MFA가 없으면 시스템은 무차별 대입 공격에 취약해지고 다른 타입의 공격에 취약해질 수 있다. 

 

불충분한 접근 통제

불충분한 접근 통제는 인가 시스템에서의 취약점 중 하나이다. 이것은 유저가 그들이 원하는 것 보다 더 많은 허가를 받는 경우에 발생하거나, 접근 통제가 적절히 인가될 수 없을 때 발생한다. 이러한 상황은 다양한 보안 사고를 야기한다. 

 

Injection 공격

Injection은 인증과 인가 시스템에서 모두 발생할 수 있는 취약점이다. Injection 공격은 공격자가 악성 코드나 악성 뎅치터를 주입하기 위해 시스템 속에서 취약점을 관찰하는 상황에서 발생할 수 있다. 이러한 상황은 비인가 접근이나 자신이 인가받은 능력보다 더 높은 지위를 얻을 수 있는 상황을 야기한다. 이러한 상황속에서 공격자는 그들이 접근할 수 없는 자원이나 행동에 접근할 수 있게 된다. 

 

수준 낮은 세션 관리

수준 낮은 세션 관리는 또한 인증 시스템에서 취약점 중 하나이다. 이 상황은 유저 세션이 부적절하게 관리되거나 다른 타입의 공격에 의해 세션이 갈취되는 상황에서 발생한다. 이러한 위험을 줄이기 위해 시스템은 세션 타입아웃이나 암호화된 쿠키를 핸들링하는 것과 같은 적절한 세션 관리 통제를 구축해야한다. 

 

 

마치며

여기까지 인증과 인가에 대해서 GPT에게 물어본 내용을 정리했습니다. 너무 글만 쭉 쓴거같아서 가독성이 떨어지는 느낌도 없지않아 있네요. 

 

구글에서 구글링을 하는 경우에는 적절한 표나 적절한 사진으로 검색하는 사람으로 하여금 이해를 많이 도와준다고 생각했는데 GPT는 그런건 얄짤없군요. 

 

아무튼 긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~

 

 

출처

Chat GPT - Open AI

 

 

 

 

'CS 지식 > 보안' 카테고리의 다른 글

JWT, 함부로 사용하면 다친다?  (0) 2024.08.18
SSL handshake / TLS handshake  (2) 2023.03.26
공개키 암호화  (0) 2023.03.21