중요정보·기능의 특성에 따라 인증방식을 정의하고 정의된 인증방식을 우회하지 못하게 설계
(입력데이터 검증 및 표현) 서버사이드 요청 위조
(보안기능) 적절한 인증 없는 중요기능 허용
(보안기능) 부적절한 인증서 유효성 검증
(API 오용) DNS lookup에 의존한 보안 결정
보안전문가들은 공공기관 사이트들이 로그인 절차를 갖추고 있음에도 개인정보가 노출된 것은 인증·권한확인 절차의 누락이 원인이라고 설명했다.
OO처럼 비공개 문서의 내려받기가 가능했던 것도 홈페이지 내에 파일처리에 관한 인증·권한확인 절차를 두지 않았기 때문인 것으로 추정했다.
OO사의 전임컨설턴트는 “기술적인 측면에서 게시판의 ‘사용자 모드’로 내부 관리자만 접근이 가능하도록 하거나 쓰기, 수정, 보기 등의 각 단계마다 일일이 보안을 걸어둬야 한다”며 “특히 관리자와 게시자만 볼 수 있게 만든 게시판의 경우에는 더욱 그렇다”고 말했다.
OO ‘고객의 소리’ 게시판에 글을 남기기 위해선 인증 과정을 거쳐야합니다.
이렇게 접속하는 방법을 정상 접근이라고 하는데, OO은 정상 접근에 대한 인증 절차만 만들고 인터넷 주소에 나타나는 고유 ID 숫자를 바꿔 접속하는 우회 접근에 대한 보안은 허술했습니다. [보안업체 관계자: 홈페이지를 요청하는 사람이 인증된 사람이냐를 확인해 줄 수 있는 3줄 정도의 시큐어코딩만 들어갔어도 이런 문제가 생기지 않는데…]
① 중요기능이나 리소스에 대해서는 인증 후 사용 정책 적용
② 안전한 인증방식 사용하여 인증우회나 권한 상승이 발생 예방
③ 중요기능에 대해 2단계(2factor)인증을 적용
① 분석단계에 분류된 중요기능에 대해 “인증 후 사용” 정책이 반드시 적용
시스템 설계 시 중요기능을 분류
식별된 중요기능에 대해 일괄적으로 인증을 요구(시스템 구성)
직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트 개발
인증기능을 제공하는 프레임워크 또는 라이브러리를 활용(중앙집중식 인증)
Java : Spring Security
ASP.NET : .NET Framework
Php : Zend Framework, Symfony
② 인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부 확인
(ㄱ) 일회용 패스워드 사용 시
일회용 패스워드 적용 시 타서비스나 시스템과의 연동 보장
일회용 패스워드를 도입 시 규칙
시각정보, 이벤트정보, 질의‐응답 방식으로 취득한 정보를 이용해 생성
시각정보 기반의 연계정보는 특정시간 동안만 유효
이벤트/질의‐응답 방식을 사용 시 연계정보를 추측할 수 없도록 보호방안 제공
일회용 패스워드 설정사항
시간적 제한을 설정(금융영역에서는 30~60초).
6자리 이상의 숫자 및 문자로 구성
OTP발생기와 인증서버에서 동일한 정보를 생성
③ 중요기능에 대해 멀티 디바이스(SMS, ARS 등)를 이용한 추가인증이나, 바이오정보(지문, 홍채 등)를 이용한 전자서명 인증기술을 이용한 2단계 인증을 고려
2단계인증의 종류 : 2개 이상의 인증기법을 사용하도록 설계
Type1(패스워드/PIN 등 지식기반인증)
Type2(토큰/스마트카드 등 소유기반인증)
Type3(지문/홍채 등 생체기반인증)
중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는 경우 중요 정보나 리소스가 노출