접근 통제와 인가
Access control · Authorization · 인가
접근 통제는 특정 가 특정 에 어떤 행동을 할 수 있는지 집행하는 과정이다. 로그인 여부뿐 아니라 소유자·조직·역할·업무 상태를 요청마다 정책에 넣는다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 다른 사용자의 객체를 읽거나 바꾸는 를 막는다.
- 일반 사용자와 관리자 기능의 경계를 집행한다.
- 검사와 실제 데이터 변경이 일관된 상태에서 이루어지게 한다.
02어떤 순서로 동작하나
- 확정
검증된 세션에서 user_id를 얻는다. 요청 본문이 주장하는 사용자 ID를 인증된 로 대신 쓰지 않는다.
- 작업과 대상 식별
조회할 주문 ID와 수행할 행동을 분리한다. ID를 안다는 사실은 접근권을 뜻하지 않는다.
- 허용 범위로 조회
서버 정책에 따라 주문 ID와 소유자 또는 허용 역할을 함께 조건으로 사용한다.
- 상태·필드 검사
업무 상태와 민감한 응답 필드의 공개 범위를 평가한다. 상태 변경이 있다면 검사와 변경의 경쟁 조건도 통제한다.
- 결과 반환과 감사
허용한 필드만 반환하거나 거부하고, 검증된 ·대상·행동·결정 이유를 감사 기록으로 연결한다.
03먼저 알아둘 용어와 구성요소
- 권한 판단의 대상이 되는 사용자·서비스 계정.
- 문서·주문·기능·필드처럼 접근을 통제할 대상.
- 역할에 권한을 부여하고 의 역할로 허용 여부를 정하는 방식.
- ··행동·환경의 속성을 조건으로 판단하는 방식.
- 동급 사용자 사이에서 타인의 객체에 접근하는 문제.
- 더 높은 권한의 기능을 허가 없이 사용하는 문제.
- 업무에 필요한 범위만 권한으로 부여하는 원칙.
- 명시적 허용 근거가 없으면 접근을 거부하는 정책.
브라우저 입력 제한을 서버 검증과 비교하기
maxlength·readonly·선택 버튼이 보안 경계가 아님을 확인하고 서버의 허용 조건을 정의한다.
실습 구성과 전제
- 의 Bypass front-end restrictions 과제를 자기 격리 환경에서 연다.
- 수정 대상은 교육용 폼으로 한정하고 운영 페이지의 권한을 우회하지 않는다.
브라우저가 제한하는 항목을 목록화한다
- 선택지·라디오 버튼·체크박스·길이 제한·readonly는 입력 편의를 위한 클라이언트 조건이다. 서버는 이 조건이 지켜졌다고 전제할 수 없다.
- 정상 요청 하나를 저장하고 각 필드의 이름·자료형·허용 값 집합을 기록한다.
원본 크기로 보기 ↗- 화면에 두 선택지·라디오·체크박스·최대 5글자·Readonly input이 함께 제시된다.
- 과제 설명은 사용자가 HTML을 바꿀 수 있음을 전제로 한다. 눈에 보이는 제한과 서버의 허용 조건을 나누는 문제다.
확인 기준제한마다 서버가 다시 검사할 조건을 대응시킨다.
DOM 변경이 요청 값에 미치는 영향을 본다
- 개발자 도구에서 교육용 입력의 value·type을 살펴본다. DOM을 수정할 수 있다는 사실은 요청 값이 신뢰 불가능함을 보여 준다.
- 서버는 UI 모양과 무관하게 필드 허용 목록, 길이, 객체 소유자·역할을 검사해야 한다.
원본 크기로 보기 ↗- input의 type·name·value·checked 속성이 표시되어 있다.
- 같은 name에 서로 다른 값과 타입이 붙을 수 있는 구조가 보인다. 서버는 중복 파라미터 처리 규칙도 명확히 해야 한다.
확인 기준DOM 변경 자체와 서버가 실제로 허용한 결과를 혼동하지 않는다.
정상·경계·거부 요청의 행렬을 만든다
- 정상 선택 값, 허용되지 않은 값, 길이 초과를 각각 한 번씩 제출하고 상태 코드와 저장 결과를 확인한다.
- 검사는 로그인된 와 대상 객체의 관계로 수행한다. 클라이언트가 보낸 사용자 ID를 권한의 근거로 믿지 않는다.
확인 기준거부 응답 뒤 데이터가 바뀌지 않았는지까지 확인한다.
실습에서 확인한 동작 원리
- 입력 UI를 바꿀 수 있는 것은 정상적인 클라이언트 특성이다.
- 보안 판단은 서버의 검증··상태 변경 경계에 있어야 한다.
동작·명령 참고 문서
Windows 계정 정책 화면을 점검 근거로 작성하기
점검 대상·판본·실제 설정·판정 조건을 구분하여 한 화면에서 확인할 수 있는 사실만 점검표에 옮긴다.
실습 구성과 전제
- 자신의 실습 에서 보안 정책을 읽기 전용으로 확인한다. 정책 변경은 관찰과 분리한다.
- 의 지정 여부와 적용 가이드 판본을 먼저 확인한다. 특정 업종이라는 이유만으로 모든 시스템이 동일 법적 점검 대상인 것은 아니다.
분야 분류를 실제 자산 목록에 대조하기
- 먼저 서버·네트워크 장비·보안 장비·DB·웹 애플리케이션 중 무엇을 점검하는지 구분한다. 같은 계정이라는 단어라도 로컬 계정과 DB 계정의 확인 위치는 다르다.
- 점검 항목 수와 번호는 판본·분야·적용 범위에 따라 달라진다. 요약 그림의 숫자를 현행 공식 점검표의 고정 분모로 삼지 않고 해당 가이드의 목록을 기준으로 범위를 만든다.
원본 크기로 보기 ↗- 가운데 주정통 점검 기준을 두고 서버, 네트워크 장비, 보안 장비, DB, 웹 애플리케이션 분야가 가지로 연결되어 있다.
- 그림의 약 400여 항목이라는 요약은 분야를 넓게 소개하는 숫자다. 개별 자산의 적용 항목 수나 현재 판본의 정확한 개수를 확정하지 않는다.
확인 기준자산 ID·OS/제품·가이드 판본·적용 항목을 연결한 뒤 설정 화면을 수집한다. 미적용 항목은 근거 없이 양호에 포함하지 않는다.
화면의 설정값과 판정 문장을 구분하기
- 로컬 보안 정책의 보안 옵션은 정책 이름과 현재 값을 보여 준다. 'Administrator 계정 이름 바꾸기'의 값이 Administrator이면 기본 이름이 그대로 관찰된 것이며, 관리자 권한 자체의 제거를 의미하지 않는다.
- 도메인에 가입된 환경에서는 정책 우선순위와 실제 적용 결과도 확인해야 한다. 한 로컬 화면만으로 전체 조직의 모든 계정 정책 상태를 대표하게 하지 않는다.
원본 크기로 보기 ↗- 보안 옵션 목록에서 Administrator 계정 이름 바꾸기 항목의 값이 Administrator로 보인다. 계정 이름 정책의 구체 관찰값을 얻을 수 있다.
- 빈 암호 사용을 콘솔 로그온으로 제한하는 항목은 사용으로 표시된다. 서로 다른 항목의 관찰값을 하나의 '계정 보안' 판정으로 합치지 않는다.
확인 기준관찰 사실을 먼저 적고 공식 점검 항목의 적용 조건·양호 기준에 대입한다. 화면에 없는 암호 복잡성이나 원격 접속 허용 상태를 추정하지 않는다.
발견 사항과 조치 후 재점검을 분리하기
- 보고서의 한 행에는 자산·항목·확인 경로·관찰값·판정 근거·영향을 기록한다. 예외 승인이나 대체 통제가 있다면 그 유효기간과 책임자를 별도 증거로 남긴다.
- 계정 이름 변경이 필요하더라도 서비스 계정 의존성과 운영 영향 검토를 거쳐 변경한다. 재점검은 변경된 설정값과 실제 인증·운영 기능을 함께 확인해야 하며, 캡처 교체만으로 끝내지 않는다.
확인 기준동일 판본의 판정 기준으로 변경 전후를 비교한다. 점검자가 관찰한 사실과 조치 담당자가 수행한 변경을 보고서에서 구별한다.
실습에서 확인한 동작 원리
- 점검은 화면 수집이 아니라 적용 조건·관찰값·판정 근거를 연결하는 작업이다.
- 정책 한 항목의 상태와 시스템 전체의 안전성·법적 적합성은 같은 결론이 아니다.
계정 정책 화면에서 관리통제의 증거 사슬 만들기
기술 설정 한 장을 자산 범위·승인·정기 검토·실제 접근 회수와 연결하여 관리체계의 설계와 운영을 구분한다.
실습 구성과 전제
- 실습 정책 화면과 가상의 계정 관리 절차를 사용한다. 특정 기관의 인증 획득이나 실제 운영 결과를 가정하지 않는다.
- 관리체계의 적용 범위·책임자·검토 주기를 문서로 정한 상태와 그 절차가 실제로 수행된 상태를 구분한다.
통제 대상의 경계를 먼저 정하기
- 자산 분류 그림에서 계정이 존재하는 시스템과 담당 부서를 찾는다. 서버만 포함했는지, DB·웹 애플리케이션·관리 장비 계정까지 포함했는지에 따라 계정 검토의 범위가 달라진다.
- 기술적 설정의 점검은 관리체계 증거의 일부다. 승인 절차·인사 변동 통보·권한 검토·시설 출입 관리가 어떻게 연결되는지도 각 통제의 책임과 증거로 정의해야 한다.
원본 크기로 보기 ↗- 서버 외에도 DB·네트워크·보안 장비·웹 애플리케이션이 별도 분야로 나뉜다. 계정 관리의 대상이 단일 OS만은 아님을 읽을 수 있다.
- 그림은 기술 분야의 범위를 보여 준다. 승인 기록이나 정기 검토가 실제 수행됐는지는 이 그림에 나타나지 않는다.
확인 기준범위 안의 자산별 계정 저장 위치와 관리 책임자를 빠짐없이 대응시킨다. 기술 점검표만으로 관리·물리 통제 전체가 충족됐다고 주장하지 않는다.
설정 증거를 절차와 운영 증거에 연결하기
- 화면의 계정 정책은 기술 통제의 현재 값을 보여 준다. 정책 문서가 요구하는 기준과 비교할 수 있지만, 누가 언제 승인하고 변경했는지는 변경 기록이 있어야 알 수 있다.
- 동일 통제를 설계 증거, 운영 증거, 효과 증거로 나누어 모은다. 가상의 계정 정책 문서, 승인된 검토 이력, 부적절한 접근이 거부되는 시험 결과는 서로 보완하는 자료다.
원본 크기로 보기 ↗- Administrator 계정 이름과 빈 암호의 콘솔 로그온 제한 등 정책별 값이 한 목록에 나타난다. 기술 통제의 관찰 지점을 구체화할 수 있다.
- 이 화면에는 정책 승인자·변경 일시·정기 검토 결과가 없다. 설정 화면을 승인이나 운영 이력의 대용으로 사용하지 않는다.
확인 기준설정값과 문서 기준이 맞는지 확인한 뒤, 승인·검토 기록의 대상 자산과 시점도 일치하는지 확인한다.
가상의 퇴사자 계정 회수에서 효과를 확인하기
- 예시 절차를 인사 통보→대상 계정 식별→권한 회수→세션 처리→완료 확인으로 나눈다. OS 계정만 잠그고 애플리케이션 세션이나 별도 DB 계정을 남기면 절차 완료와 접근 회수가 어긋날 수 있다.
- 가상의 시험 계정으로 승인된 범위의 로그인과 기존 세션을 시험하고, 거부 결과·남은 권한·처리 시각을 기록한다. 실패가 발견되면 담당자와 기한을 정해 보완한 뒤 같은 조건으로 재확인한다.
확인 기준절차 문서가 존재하는지, 실제 처리 기록이 있는지, 접근이 더 이상 허용되지 않는지 세 질문을 각각 답할 수 있어야 한다.
실습에서 확인한 동작 원리
- 관리체계는 정책의 존재뿐 아니라 적용 범위와 수행·효과 증거를 함께 평가한다.
- 캡처에 나타난 사실을 넘는 승인·인증·운영 성공 주장은 별도 증거가 필요하다.
04예제로 따라가기
- 초기 상태: 주문 42의 소유자=A, 상태=OPEN, 버전=7이라고 가정한다. A의 두 요청이 모두 이 화면을 읽었다.
- 첫 요청: 서버가 id=42·owner=A·state=OPEN·version=7을 조건으로 CANCELLED와 version=8로 바꾼다. 영향 행은 1개다.
- 두 번째 요청: 같은 version=7 조건을 다시 적용하면 현재 버전과 달라 영향 행은 0개다. 취소 후 환불을 두 번 실행해서는 안 된다.
- 다른 사용자: B의 요청은 owner 조건에서 실패한다. A의 버전 값을 정확히 알더라도 소유권 조건을 통과하지 못한다.
- 부수 효과: 환불·알림처럼 DB 밖에서 실행되는 작업은 별도의 멱등 키와 결과 상태가 필요하다. DB 행 조건만으로 외부 호출 중복까지 해결되지는 않는다.
05혼동하기 쉬운 점과 확인 기준
- 객체 범위: 목록은 Tenant로 제한했지만 상세·내보내기·첨부 다운로드에는 같은 제한이 빠졌는지 경로별로 비교한다.
- 캐시 키: 캐시가 URL만 사용하고 사용자·권한 문맥을 구분하지 않으면 올바른 첫 응답을 다른 에게 재사용할 수 있다.
- 필드 권한: 객체 수정 권한이 있어도 소유자·역할·승인 상태를 임의 변경할 수 있다는 뜻은 아니다. 입력 필드별 허용 범위를 확인한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.