접근 규칙

접근 규칙에서 세션 시작, sudo 사용, 명령어 실행 시 처리할 방식을 정합니다. 기본 개념은 접근 결정 방식을, 정확한 기본값과 플랜 요건은 참조 문서를 참고하세요.

접근 규칙 열기#

콘솔에서 Policies → 접근 규칙을 여세요. 모든 배포 환경에서 approval_policy:read 권한이 있는 워크스페이스 관리자가 이 페이지에 접근할 수 있으며, 슈퍼유저는 항상 접근할 수 있습니다. 다른 멤버에게는 규칙 목록과 메뉴가 표시되지 않습니다.

승인 규칙을 만들거나 수정하거나 삭제하려면 각 작업에 해당하는 approval_policy 권한이 필요합니다. 상시 sudo 정책은 해당 sudo_policy 권한이 필요합니다. 따라서 화면에 보이는 항목이라도 편집할 수 없을 수 있습니다. sudo 설정은 워크스페이스 권한과 배포 환경의 MFA 지원 여부에도 영향을 받습니다. 서버 접근을 참고하세요.

개요와 작업별 탭 확인#

먼저 개요에서 서버 그룹을 선택하세요. 셀을 선택하면 해당 주체의 작업 결과를 결정하는 규칙이 표시됩니다. 그룹에 속하지 않은 서버도 확인하세요. 그룹 규칙은 그런 서버와 일치하지 않습니다.

sudo 탭의 웹 터미널에는 워크스페이스에서 추가 MFA 인증을 지원할 때 결과가 MFA 후 허용인 상시 sudo 정책이 표시됩니다. CLI·API에는 허용, 승인 요청, 차단을 결정하는 승인 규칙이 있습니다. 해당 영역의 안내를 따르세요. 여기서 실행하는 sudo도 명령어 규칙으로 판정해요.는 CLI·API의 sudo 규칙이 웹 터미널 sudo도 결정한다는 뜻입니다. Try it로 선택한 경로를 확인하세요.

규칙 추가와 편집#

1. 작업 탭을 선택하고, sudo라면 실행 경로도 선택하세요. 새 규칙을 선택하거나 기존 워크스페이스 규칙을 여세요.
2. 규칙 문장에서 밑줄이 있는 부분을 선택하세요. 대상, 적용 위치, 결과를 정합니다. 위험도를 평가하는 명령어와 sudo 규칙에는 AI 위험도도 지정할 수 있습니다. 세션 승인에는 명령어 위험도가 없습니다.
3. 승인이 필요하면 플랜에서 지원하는 승인자 수와 승인자 지정 방식을 선택하세요. 요청자가 자신의 요청을 결정하지 못하게 하려면 요청자 본인 승인 불가를 선택하세요.
4. 추가 옵션에서 알아보기 쉬운 이름을 정하고, 필요하면 종료일도 지정하세요. 종료일은 저장 시점 이후로 정해야 합니다. 종료일이 없으면 끄거나 삭제할 때까지 계속 적용됩니다.
5. 미리 시험으로 초안을 확인한 뒤 규칙 저장을 선택하세요. 미리보기만으로 규칙이 저장되지는 않습니다.

설정할 수 있는 항목은 작업마다 다릅니다. 상시 터미널 정책은 사람, 개별 서버, 명령어 패턴을 지정합니다. 승인 규칙은 요청자 종류나 역할, 서버 그룹을 사용합니다. 편집 항목이 없는 기존 조건은 저장할 때 유지되지만, 새로 설정할 수 있는 항목은 아닙니다. 작업별 조건을 참고하세요.

규칙 평가 순서 설정#

순서를 바꿀 수 있는 승인 규칙 목록에서 워크스페이스 규칙을 원하는 위치로 드래그하세요. 순서 변경 버튼에 초점을 두고 Alt+↑ 또는 Alt+↓를 사용할 수도 있습니다. 해당 목록에서 처음 일치한 활성 규칙이 결과를 결정합니다. 좁은 범위의 예외를 우선하려면 더 넓은 규칙보다 위에 놓으세요.

워크스페이스 승인 규칙을 기본 규칙보다 먼저 확인합니다. 꺼져 있거나 만료된 규칙은 결과를 결정하지 않습니다. 기본 검사와 상시 sudo 정책이 모두 하나의 순서 변경 목록에 속하는 것은 아닙니다. 표시된 판단 과정에서 각 검사와 정책이 적용되는 단계를 확인하세요. 순서를 바꿔도 범위나 계정 검사에서 거부된 작업을 허용할 수는 없습니다.

저장 전 미리보기#

선택한 작업에서 Try it를 열거나 편집기의 초안 미리보기를 사용하세요. 사람, 에이전트 또는 서비스 토큰과 대상 서버나 그룹을 선택하고, 해당하는 경우 명령어를 입력하세요. 위험도를 평가하는 작업에서는 위험도를 지정하거나, 지정하지 않은 채 위험도별 결과를 비교할 수 있습니다.

결과, 결과를 결정한 규칙, 승인자, MFA 요건을 확인하세요. 일치하지 않은 규칙은 판단 과정에서 이유를 확인할 수 있습니다. 의도한 조건에 맞는 경우와 조건 하나가 달라지는 경우를 모두 확인하세요. 그룹에 속하지 않은 서버도 포함하세요.

예제: 프로덕션 서버의 에이전트 세션 승인#

에이전트 세션은 기본적으로 사람의 승인이 필요합니다. 에이전트 세션을 자동 허용하는 더 넓은 규칙이 있더라도 production 그룹의 서버에서는 사람의 승인을 받게 하려면 이 예제를 사용하세요. 이 규칙을 더 넓은 허용 규칙보다 위에 놓으세요.

1. 세션 열기를 열고 새 규칙을 선택하세요.
2. AI 에이전트와 production 서버 그룹을 선택하세요. 모든 에이전트에 적용하려면 에이전트 이름 조건은 비워 두세요.
3. 결과를 승인 요청으로 정하고 승인자 한 명을 요구하세요. 다른 사람의 승인이 필요하면 요청자 본인 승인 불가를 켜세요.
4. 프로덕션 서버의 에이전트를 미리보기로 확인하세요. 승인할 수 있는 사람이 표시되는지 확인합니다. 사람, 그룹 밖의 에이전트, 그룹이 없는 서버도 확인하세요.
5. 저장한 뒤, 해당 에이전트를 자동 승인하는 더 넓은 규칙이 있다면 그 위에 놓으세요.

이 규칙은 세션 시작을 결정합니다. 제출하는 명령어마다 검토가 필요하면 명령어 실행에도 같은 대상의 승인 규칙을 만들고, 그 작업을 별도로 확인하세요.

예제: 역할별 sudo 위험도 범위 허용#

operator 전역 역할을 가진 사람이 staging 그룹 서버에서 높음 위험도까지 sudo를 사용할 수 있도록 사전 승인하는 예제입니다. 사람의 sudo는 기본 위험도 검사에서 이미 중간까지 허용하며, 높음은 기본적으로 승인이 필요합니다.

1. sudo 사용을 열고 CLI·API를 선택하세요.
2. 규칙을 만들고 역할에서 operator 역할과 staging 그룹을 선택하세요.
3. 위험도를 높음까지로 정하고 허용을 선택하세요.
4. 해당 역할을 가진 사람이 staging 서버에서 높음 위험도의 작업을 하는 경우, 위험도 규칙이 허용하는지 미리보기로 확인하세요. 심각 위험도는 자동 허용되면 안 됩니다. 역할이 없는 사람과 그룹 밖의 서버도 확인하세요. 다른 규칙이 일치하지 않으면 높음 위험도에는 승인이 필요합니다.
5. 의도한 순서로 규칙을 저장하세요. 범위 밖의 경우에는 적절한 후순위 규칙이나 기본값이 적용되는지 확인합니다.

여기서 역할 조건은 세션을 사용할 사람의 역할을 뜻합니다. 사용자 그룹 소속 여부가 아닙니다. 위험도 판단에서 sudo를 허용하더라도 세션에 sudo 범위가 있어야 하며, 그 사람의 최근 MFA 확인도 필요합니다. 웹 터미널 영역에 여기서 실행하는 sudo도 명령어 규칙으로 판정해요.가 표시되면 이 규칙을 포함한 CLI·API의 sudo 규칙이 웹 터미널 sudo도 결정합니다. 따라서 이 규칙을 완화하면 웹 터미널 sudo의 제한도 완화됩니다. 상시 권한 검사는 계속 적용됩니다.

예제: 지정한 사람의 터미널 sudo를 MFA 후 허용#

지정한 사람이 선택한 서버에서 정해진 유지보수 명령어를 써야 할 때 사용합니다. MFA 후 허용 결과는 워크스페이스에서 해당 사람에게 추가 MFA 인증을 요청할 수 있을 때만 표시됩니다.

1. sudo 사용을 열고 웹 터미널에서 새 규칙을 선택하세요.
2. 사람과 개별 서버를 선택하세요. systemctl restart postgresql처럼 범위가 좁은 명령어 패턴을 지정합니다. 와일드카드를 쓰기 전에 sudo 명령 패턴을 확인하세요.
3. 제공되는 결과인 MFA 후 허용을 유지하세요. 임시 권한이라면 종료일을 정하세요.
4. 해당 사람, 서버, 명령어를 미리보기로 확인하세요. 사람이나 서버, 명령어가 다른 경우와 비교하고, 결과에 범위·위험도·MFA 제한이 표시되는지 확인합니다.
5. 저장한 뒤 sudo가 포함된 작업 세션을 사용하세요. MFA를 요청받으면 인증합니다.

이 정책은 지정한 명령어에 상시 권한을 부여하며 MFA를 없애지는 않습니다. 한 작업 세션이 끝날 때 함께 종료할 권한이라면 세션에 연결된 sudo 정책을 요청하세요. 세션 승인이 MFA를 대신하도록 할 수 있으며, 세션이 끝나면 정책도 비활성화됩니다. MFA로 sudo 사용을 참고하세요.

예제: 애플리케이션 하나의 서비스 토큰 실행 제한#

배포 작업은 해당 애플리케이션의 토큰 설정에서 제한하세요. 접근 규칙 편집기에는 새 위험도 규칙을 만들 때 애플리케이션이나 토큰을 고르는 항목이 없습니다.

1. IAM에서 애플리케이션을 열고 토큰을 선택하세요. 작업에 사용하는 승인된 토큰을 여세요.
2. ACL에서 허용할 서버와 파일 작업을 제한하세요. 자체 호스팅 배포에서는 명령어 접근 규칙도 여기서 설정합니다.
3. Alpacon Cloud에서는 사전 승인된 명령에서 필요한 명령어만 사전 승인하세요. 슈퍼유저도 명령 ACL 관리자 멤버여야 합니다. 서비스 토큰으로 명령어 허용 절차를 따르세요.
4. Try it로 돌아가 sudo/명령어를 확인할 구체적인 서비스 토큰을 선택하세요. 그룹에 속한 서버와 그룹이 없는 서버를 모두 확인하고 위험도별로 비교합니다. 토큰 접근 규칙과 별도로 위험도 판단을 확인하는 과정입니다.
5. 작업을 실행하기 전에 토큰의 허용 서버와 명령어 항목을 각각 확인하세요. 범위 밖의 서버나 명령어가 사전 승인되지 않았는지 확인합니다.

기존 애플리케이션별 위험도 규칙도 결과에 영향을 줄 수 있습니다. 이런 제한은 지정한 애플리케이션이나 토큰에 적용되며, 서버 그룹 조건까지 추가하면 그 그룹 안에서만 적용됩니다. 그룹 조건만 사용한 제한은 그룹이 없는 서버에 적용되지 않아 기본값으로 처리됩니다. 작업 세션 없는 명령어는 승인을 기다리지 않습니다. Enforce에서는 어떤 위험도 규칙도 CRITICAL 토큰 실행을 자동 승인할 수 없으며, 작업 세션 없는 CRITICAL 명령어는 거부합니다. Alpacon Cloud에서 enforce를 사용하면 이런 명령어가 사전 승인된 원장 항목과 일치해도 심각 위험도 차단 기준에 따라 거부합니다. Advisory에서는 심각 위험도 차단 기준에 해당하는 토큰 실행도 위험도 검사에서 자동 승인합니다. Alpacon Cloud에서는 두 모드 모두 사전 승인된 원장 항목과 일치해야 합니다. 서비스 토큰 실행 기본 규칙을 참고하세요.

저장한 결과 확인#

저장한 규칙을 다시 열고 실제 작업 주체와 대상을 넣어 미리보기를 반복하세요. 규칙 순서, 켜짐 여부, 만료일, 배포 환경 안내, 워크스페이스 모드를 확인합니다. Advisory에서 나온 결과만으로 enforce에서도 실행된다고 판단할 수는 없습니다.

실제 작업을 시도한 뒤에는 작업 종류에 맞춰 명령, Privilege elevation, 대기 중인 요청을 확인하세요. sudo 기록에는 어떤 근거로 접근을 허용했는지도 남습니다. 현재 요청 상태도 확인해야 합니다. 거절되거나 철회되거나 만료된 승인 요청은 더 이상 대기 중이 아닙니다. 다음 조치는 오류 코드 안내를 참고하세요.