수정하기 - 웹서버구축을 위한 사용자 인증 및 인가 방식은?

닉네임

비밀번호

제목

내용 [이미지 업로드는 권한이 있는 사람만 가능. 하단 카톡으로 연락]

웹서버를 구축할 때 가장 기본적이면서도 핵심이 되는 기능이 바로 ‘누가(Authentication)’, ‘무엇을 할 수 있나(Authorization)’를 판별·통제하는 것입니다. 다음에서는 대표적인 인증·인가 방식을 종류별로, 또 보안·운영관점의 주요 고려사항을 함께 설명합니다.      1. Authentication(인증) 방식    1) 아이디·패스워드 기반      - 기본형(form-based)        사용자는 로그인 폼에 아이디(ID)와 비밀번호(PW)를 입력하고, 서버는 이를 DB나 인증서버(예: LDAP, Active Directory)와 비교합니다.        핵심 포인트        · Password는 절대 평문 저장 금지(BCrypt, Argon2, PBKDF2 같은 느린 해시 함수와 솔트 사용).        · TLS/HTTPS로 전송 구간 암호화.        · 로그인 시도 횟수 제한, 캡차 도입 또는 계정 잠금 기능.        - HTTP Basic/Digest 인증        HTTP 헤더(Authorization 필드)에 사용자 자격 증명(기본형은 Base64, Digest는 해시 기반)을 넣어 보내는 방식입니다.        장점은 구현이 간단하나, Basic 인증은 Base64 인코딩 수준으로 안전하지 않고, Digest 인증도 현재는 지원이 제한적입니다. 반드시 HTTPS와 함께 써야 합니다.      2) 세션·쿠키 기반 인증      - 로그인 성공 시 서버가 고유한 세션ID를 발급하고, 클라이언트 쿠키(cookie: session_id=…)에 저장해 이후 요청마다 함께 보냅니다.      - 서버는 세션 저장소(메모리, Redis, DB 등)에 세션ID별 사용자 정보를 보관하고 조회해 인증 상태를 유지합니다.      보안요소        · 쿠키에 HttpOnly, Secure, SameSite 속성 설정.        · 세션 타임아웃, Idle 타임아웃 정책.        · 세션 고정(session fixation)·탈취(session hijacking) 방어(로그인 시 세션 재발급).      3) 토큰 기반 인증 (Stateless)      - JWT(JSON Web Token)        서버가 로그인 시 페이로드에 사용자 ID, 권한(scope) 등을 담아 서명된 토큰을 발급.        클라이언트는 이 토큰을 Authorization: Bearer <token> 헤더에 실어 보냅니다.        서버는 매 요청마다 서명을 검증해 사용자 식별과 권한을 확인합니다.        특징          · 서버 측에 상태를 거의 남기지 않아 수평 확장(水平拡張)에 유리.          · 토큰 탈취 시 위험이 크므로 만료시간(exp), 리프레시 토큰(rotation) 등을 도입.        - OAuth 2.0 / OpenID Connect        권한 위임·SSO 환경에서 주로 사용됩니다.        · OAuth 2.0: 리소스 소유자(사용자)가 클라이언트에게 특정 자원에 대한 접근 권한을 부여(예: GitHub API 호출). 토큰 발급(grant types: authorization code, client credentials 등).        · OpenID Connect: OAuth 2.0 위에서 ID 토큰(IdToken)을 추가해 인증(누구인가)까지 제공. SSO, 소셜 로그인 시 주로 활용.      4) 다중 요소 인증(Multi-Factor Authentication, MFA)      - ‘지식(Knowledge)’ + ‘<a href='https://sangseek.com/sangseeks/소지/ko'>소지</a>(Possession)’ + ‘생체(Inherence)’를 조합.      - 예: ID/PW + TOTP 앱(Google Authenticator), SMS/이메일 코드, 하드웨어 OTP 토큰, FIDO2/WebAuthn(생체 지문·안면인식) 등.      - 로그인 단계별로 추가 인증 요구 → 보안 강화      5) 인증서 기반(공개키 기반)      - <a href='https://sangseek.com/sangseeks/mTLS/ko'>mTLS</a>(mutual TLS)        서버와 클라이언트가 서로 인증서를 교환하여 TLS 핸드셰이크 단계에서 인증.        B2B, 기계 대 기계 통신, 사내망 보안 터널 구축 등에 적합.      ---    2. Authorization(인가) 방식    1) Role-Based Access Control(RBAC)      - 사용자(User) → 역할(Role) → 권한(Permission) 간 매핑 구조.      - 예: Alice는 ‘관리자(Admin)’ 역할, Bob은 ‘<a href='https://sangseek.com/sangseeks/일반사/ko'>일반사</a>용자(User)’ 역할. Admin은 CRUD, User는 조회만 가능.      장점: 구성 및 관리가 비교적 단순      단점: 세분화된 권한 표현엔 한계가 있고, 역할이 많아지면 복잡해짐      2) Attribute-Based Access Control(ABAC)      - 사용자 속성(부서, 등급 등), 자원 속성(파일유형, 소유자 등), 환경 속성(IP, 시간대 등)을 정책 언어(POLICY)로 기술하여 동적 검증.      - 예: ‘근무시간(9~18시)에 사내 IP에서만 인사 파일 열람 허용’.      장점: 세부·복잡한 정책 처리 유연      단점: 정책 설계·유지보수·성능 관리가 까다로움      3) Access Control List(ACL)      - 객체(파일, API 엔드포인트 등) 별로 허용된 사용자나 그룹을 나열.      - ‘/reports/finance.pdf’ 읽기 허용: Alice, Bob; 쓰기 허용: Alice만.      간단하지만 대규모 시스템에서는 관리 포인트가 많아짐      4) Policy-Based Access Control(PBAC)      - 중앙 정책서버(Policy Decision Point, PDP)가 한 곳에서 모든 인가 요청을 평가하고, 서비스들(Policy Enforcement Point, PEP)은 PDP에 질의하여 허용/거부 여부를 받음.      - 중앙 집중형 <a href='https://sangseek.com/sangseeks/정책 관리/ko'>정책 관리</a>, 감사(audit) 일원화 가능      5) 세분화된 권한 관리      - 객체 수준(Object-level), 필드 수준(Field-level) 인가      - 예: 주문 데이터 전체 보기, 금액 정보 읽기 금지 등      ---    3. 통합 운영·보안 고려사항    1) HTTPS/TLS 필수화      인증정보·토큰·쿠키 모두 반드시 암호화된 전송 채널로만 교환.      2) 비밀번호·토큰·API 키 보호      - 해시·암호화 저장, 주기적 키 교체, 최소 권한 원칙(Least Privilege).      3) 로그인·인가 로그·감사      - 누가 언제 어떤 자원에 접근·시도했는지 기록.      - 비정상 시도 차단·알림(IDS/IPS 연계).      4) 세션·토큰 만료      - 세션 무한유효(X), 토큰 유효기간 엄격 설정.      - 로그아웃 시 서버·클라이언트 양쪽에서 세션·토큰 폐기.      5) 보안 헤더      - CSP(Content-Security-Policy), X-Frame-Options, X-Content-Type-Options, HSTS 등 설정.      6) 자동화된 테스트·취약점 스캐닝      - 정적 분석, 동적 분석, 모의해킹을 통해 인증·인가 로직 점검      7) 확장성·장애 대응      - 인증·인가 컴포넌트를 마이크로서비스 형태로 분리하거나, 외부 IdP(identity provider) 서비스를 이용해 수평 확장      - 캐시·세션 클러스터링, 로드밸런서 연계      8) SSO·Federation(연합 인증)      - 기업 내부 여러 애플리케이션을 하나의 로그인으로 묶거나, 파트너사 간 신뢰 연계      - <a href='https://sangseek.com/sangseeks/SAML 2.0/ko'>SAML 2.0</a>, OpenID Connect, OAuth2 이용      9) 개발 프레임워크·라이브러리 활용      - Spring Security, ASP.NET Identity, Django Auth, Passport.js 등 검증된 솔루션 사용으로 보안 구현·유지 편의성 확보      종합하면, 웹서버 구축 시 인증(Authentication) 단계에서는 ‘사용자 식별’과 ‘자격 증명 검증’을, 인가(Authorization) 단계에서는 ‘식별된 사용자(또는 서비스)가 어떤 자원에 어떤 행위를 할 수 있는지’ 결정·통제하게 됩니다.단순 아이디·비밀번호부터 세션·쿠키, JWT 같은 토큰, OAuth2/OpenID Connect, 다중 요소, mTLS, SSO, RBAC·ABAC·PBAC 등 여러 기법을 조합하되, TLS <a href='https://sangseek.com/sangseeks/보안 전송/ko'>보안 전송</a>, 안전한 자격 증명 저장, 최소 권한 원칙, 세션·토큰 만료·폐기, 감사 로깅, 보안 헤더·취약점 점검 같은 운영·보안 수칙을 반드시 지켜야 합니다.