Session 방식은 서버가 Session을 생성 및 저장하고 클라이언트에게 보냈다가 클라이언트의 요청 시 두개의 값을 비교하여 허용된 클라이언트인지를 식별하는 방식이라면, JWT Token 방식은 이와 다르게, 인증 과정을 거친 후에 클라이언트의 정보를 이용하여 자신의 Private key로 Token을 생성하고 클라이언트에 보낼 뿐 서버가 이를 저장하지 않으며, 클라이언트 요청 시 보내온 JWT가 자신의 Private key로 발행한 Token인지를 확인함으로써 허용된 […]
최근 JWT(JSON Web Token)기반으로 사용자 인증 및 권한 관리를 구현하는 경우가 많아졌다. JWT는 전통적인 session 방식과 다르게, 서버에 인증 정보를 갖지 않아도 되는 특장점들이 있기 때문에 기존의 전통적인 session기반의 인증 처리와 함께 사용 범위가 확대되고 있다. JWT 토큰 생성하는 부분을 개발할 때, 클라이언트의 특징 정보들을 활용하여 JWT보안 강화하는 방법들이 몇 가지 있으며, 서비스 환경과 목적에
JWT(JSON Web Token) 개발 시 보안 원칙 Microservice Architecture기반의 개발이 많아지면서 독립적인 Microservice들 간의 클라이언트(사용자 또는 시스템) 인증 및 권한을 위해 사용되는 주요 기술들을 요약하면 아래와 같다. – JSON Web Token(JWT)– OAuth 2.0– API Gateway(중앙집중식 인증관리)– Service Mesh– Mutual TLS(mTLS)– IAM Platform 이중에서 JWT기술은 대표적인 기술이며 개발 현장에서 JWT형식의 Token을 생성하여 Session에 넣어서 사용하는 것이 일반적이다. 그리고
WT(JSON Web Token)는 Session방식과 다르게, JWT 자체로 필요한 인증 및 권한정보를 포함하는 상태로 설계되어 있기 때문에, 전통적인 Session기반의 인증방식과는 다르게 서버 측에서 JWT Token을 별도로 저장할 필요가 없다. 그러나 Token Whitelisting 또는 Blacklisting을 위해 JWT를 서버에 저장하는 경우도 있다. JWT방식은 왜 등장하게 되었는가? 기존의 전통적인 Session방식은 stateful방식으로써 모든 클라이언트의 session정보를 서버(데이터베이스나 캐시)에 저장하고 있어야 한다.
Session ID, Access Token, JWT 특성 비교 Session ID, Access Token, JWT(JSON Web Token)은 사용자(또는 시스템)에 대한 인증 및 권한부여를 위해 사용되는 대표적인 기술이다. 이 기술들은 실제 복합적으로 사용되지만 각기 목적과 저장위치, 생성 및 관리상의 특성이 있기 때문에 이를 잘 이해해야 적합한 기술을 유효적절하게 선택할 수 있을 것이다. 구분 목적 생성 방법 저장 위치 관리
1. S/W공급망보안을 위한 개발사(개발조직)과 운영사(운영조직)간 역할 2. S/W운영사를 위한 SBOM보안 취약점 스캐너 3. SBOM OSS 취약점 스캐닝 웹사이트 사용법: SBOM취약점스캐너 https://sbomvul.wikisecurity.net/Step 1. 텍스트 상자를 클릭하여 Windows 탐색창으로 JSON 형식의 SBOM 파일을 선택한다.Step 2. ‘SUBMIT’ 버튼을 클릭하여 선택한 SBOM 파일을 서버에게 제출한다.Step 3. 제출된 SBOM 파일에서 오픈 소스 패키지에 대한 보안 취약점 검사 결과를 확인한다.
최근 과학기술정보통신부(한국인터넷진흥원), 국가정보원, 디지털플랫폼정부위원회가 합동으로 ‘소프트웨어(SW) 공급망 보안 가이드라인 1.0’을 공개하여 많은 기업과 기관들이 공급망보안과 함께 SBOM에 대한 내부 논의가 이뤄지고 있을 것으로 생각한다. 그러나 공개된 SW공급망 보안 가이드라인 1.0에 정의된 SBOM 표준 규격에 취약점 정보속성을 통합하는 것은 SW개발사, 공급사, 운영가들 모두가 잘 이해해야 하는 부분이 있다. 이를 참고하여 개발사, 공급사, 운영자가 효율적인 SW공급망 보안이
반드시 준비해야 하는가? 오픈소스 소프트웨어 이용에 대해, 전자금융감독규정 제21조(정보처리시스템 구축 및 전자금융거래 관련 계약)에서는, “5. 구매 또는 개발한 제품의 소유권, 저작권 및 지적재산권 등의 귀속관계를 명확히 하여 사후 분쟁이 발생하지 않도록 할 것”이라고 명시되었으며, 이 조항은 최근에 추가된 것이 아니라 이미 2013년부터 존재하고 있었고, RFP와 같이 계약서와 이에 준하는 서류에 명시되어 있었으나 구체적인 요구사항이나 가이드가
