NetSuite 역할 및 권한에 대한 심층 분석

사용자 역할에 대해 명확하고 확신 있는 이해는 NetSuite를 성공적으로 관리하는 데 필수입니다. 새로운 계정을 도입하든, 기존 계정을 정리하든, 또는 SOX compliance를 위한 직무 분리(Separation of Duties)를 설정하든, 몇 가지 핵심 원칙을 확실히 이해하고 있어야 합니다.

사용자 역할 이해

NetSuite에는 역할 기반 액세스 제어 시스템이 있습니다. 즉, 각 사용자가 시스템에 액세스하려면 사용자에게 역할이 할당되어야 하며, 그 역할이 시스템에서 사용자가 볼 수 있는 것과 수행할 수 있는 작업을 결정합니다.

총 4923개의 서로 다른 작업, 검색 및 기록을 관리하는 636개의 개별 권한이 있습니다. 또한 각 역할에는 모든 레코드 및 거래 유형에 대해 선호 목록 보기 또는 필수 목록 보기(또는 양식)가 설정될 수 있습니다. 그뿐만 아니라, 서로 다른 세그먼트와 자회사에서 사용자가 보게 되는 데이터가 무엇인지 제어하는 모든 문맥(컨텍스트) 설정이 함께 존재합니다. 계정의 성격에 따라, 이 조합 가능성은 수십만 가지에 이를 수 있습니다.

하지만 현실은 대개 그렇게 복잡하지 않습니다. 간단히 말해, 역할은 세 가지로 구성됩니다:

• 권한: 사용자가 데이터를 보고, 그 데이터를 기반으로 작업을 수행할 수 있는 권리를 부여합니다.
• 제한 사항: 권한의 사용을 자회사, 부서 또는 클래스와 관련된 데이터로 한정하세요.
• 인터페이스: 폼, 목록 보기, 대시보드와 같은 요소와, ‘center’로 알려진 전반적인 내비게이션 테마는 사용자가 정보를 어떻게 보게 되는지를 정의합니다.

사용자 권한 이해하기

각 사용자 역할(관리자 제외)은 최소한 하나의 권한이 필요합니다. 본질적으로 권한은 사용자가 시스템에서 할 수 있는 것과 할 수 없는 것을 규정하는 권리의 묶음입니다.

대부분의 권한에는 View부터 Full까지 다양한 권한 수준 범위가 있습니다. 그 종류는 다음과 같습니다:

• 보기: 사용자는 데이터를 볼 수는 있지만 변경할 수는 없습니다.
• 생성: 사용자는 ALSO 기록 또는 거래를 생성할 수는 있지만, 편집할 수는 없습니다.
• 편집: 사용자는 ALSO 생성된 기록 또는 거래를 변경할 수 있습니다.
• 전체: 사용자는 ALSO 레코드 또는 트랜잭션을 삭제할 수도 있습니다.

거의 누구에게나, 거의 모든 것에 대해 Full 권한 수준을 부여할 때는 매우, 매우 주의해야 합니다. 거의 어떤 운영 역할도 Full로 설정된 트랜잭션 권한을 가져서는 안 됩니다.

사용자 권한에 관한 FAQ 4가지

관리자(Admin) 역할에는 어떤 권한이 있나요?

관리자는 모든 권한을 가지며, 누구에게나 액세스를 부여할 수 있고, 전체 계정을 삭제할 수도 있습니다. 따라서 Admin 액세스를 제공할 대상은 매우 신중하게 선택해야 합니다. 꼭 기억해야 할 한 가지는 관리자 역할에 포함된 거의 모든 기능이 별도의 권한으로도 제공된다는 점입니다. 권한을 이해하는 가장 좋은 방법은 권한을 단축 경로로 생각하는 것입니다. 즉, 관리자가 한 단계로 역할에 기능 그룹을 한꺼번에 부여할 수 있게 해주는 것입니다.

작업(Task)이란 무엇인가요?

많은 권한은 작업(Task)과 관련해 설명됩니다. 이러한 관계는 권한에 대해 혼란이 생기는 주요 원인 중 하나입니다. 그렇다면 작업(Task)이란 무엇일까요?

작업은 기본적으로 NetSuite에서 어떤 작업을 수행하기 위한 경로입니다. 이는 항상 하나 이상의 인터페이스 요소로 표현됩니다. 이러한 요소는 탐색(내비게이션)에 있을 수도 있고, 레코드 또는 거래 인터페이스 안에 있을 수도 있습니다.

예를 들어, “Sales Order Approval” 권한은 “Sales Order Approval” 작업을 켜고 끄는 역할을 합니다. 이 권한이 없으면 사용자는 판매 주문을 승인할 수 없습니다.

권한은 탐색(내비게이션)에 어떤 영향을 미치나요?

“View(보기)” 권한 수준은 탐색(내비게이션)을 제어하며, 경우에 따라 대시보드에 알림을 추가할 수 있는 권한도 제어합니다. 나머지 수준은 레코드, 거래 또는 설정에서 데이터를 생성, 변경 또는 삭제할 수 있는 권한을 제어하며, 그 결과 버튼을 추가하거나 승인 상태를 활성화하는 등 인터페이스의 기능이 달라질 수 있습니다.

이는 데이터와 거래에만 해당하는 것이 아니라, 위에서 언급한 모든 구성 권한에도 그대로 적용됩니다. 또한 해당 기능이 작업(task)이라고 불리든 레코드(record)라고 불리든, 권한과의 기능적 관계는 동일하므로 크게 중요하지 않습니다.

NetSuite 역할과 권한의 다양한 카테고리는 무엇인가요?

• 거래(Transactions): 이러한 권한은 NetSuite의 거래 기록에 대한 액세스와 이를 승인할 수 있는 권한을 제어합니다. 업무 분장 원칙을 적절히 보장하기 위해 특정 역할에 따라 제한된 권한을 할당하는 것이 중요합니다. 또한 특정 역할이 거래와 관련된 SuiteFlow 워크플로를 구성하는 데 필요한 권한이 있는지 고려해 보세요.
• 보고서(Reports): 이러한 권한은 NetSuite 내에서 더 광범위한 재무 보고에 대한 액세스를 결정합니다. 재무 보고에 관여하는 역할은 일반적으로 이러한 권한의 대부분이 할당됩니다.
• 목록(Lists): 이 카테고리는 고객, 공급업체, 직원 등 NetSuite의 모든 비거래(non-transaction) 레코드에 대한 액세스를 다룹니다. 이 카테고리의 모든 권한이 직관적으로 이름이 지정되어 있지 않을 수 있으므로, 각 권한의 목적을 이해하기 위해 신중하게 검토하세요. “Mass Updates” 같은 일부 관리자 권한은 소수의 사용자에게만 제한해야 합니다.
• 설정(Setup): 이러한 권한은 대부분 관리 목적으로 사용됩니다. 다만 이 카테고리의 일부 권한은 더 다양한 역할과 관련이 있을 수 있습니다. 예를 들어, “Import CSV File” 권한을 통해 최종 사용자는 자신에게 액세스 권한이 있는 레코드에 대해 자신의 CSV 가져오기를 처리할 수 있습니다. 또한 “SAML Single Sign-on” 권한은 단일 로그인 인증(single sign-on authentication)을 사용하는 역할에 필수입니다.
• Custom Record: 이 범주는 NetSuite 내 SuiteApps 또는 사용자 지정 레코드에 해당합니다. 특정 레코드 또는 레코드 그룹에 대한 접근 권한은 사용자의 역할에 따라 사용자에게 부여할 수 있습니다. 새로운 SuiteApp을 구현하는 동안에는, 사용자가 필요에 따라 해당 솔루션과 상호작용할 수 있도록 이러한 권한을 종종 조정합니다.

관리자 동작 모니터링

NetSuite에서 관리자(Administrator) 역할은 사용자에게 광범위한 트랜잭션 권한을 부여하며, 그만큼 사기(부정행위)의 가능성도 함께 따릅니다. 이상적인 환경이라면, 어떤 단일 사용자는 운영 계정(production account)에서 트랜잭션을 생성, 수정, 삭제할 수 없어야 합니다.

관리자 권한이 있는 사용자가 수행한 모든 트랜잭션 변경 사항을 정기적으로 모니터링하고 검토하는 것은 SOX 컴플라이언스를 준비하는 핵심 요소입니다. 이는 물론 안전을 유지하기 위한 모범 사례이기도 합니다. 그러나 이러한 변경 사항을 탐지하는 일은 생각보다 더 어렵습니다. 그 결과, 팀을 완전히 신뢰하더라도 감사 대응(audit readiness)은 어려운 과제가 될 수 있습니다.

문제의 근본 원인은 NetSuite에서 일부 스크립트와 워크플로우가, 관리자 권한을 가진 사용자가 직접 트리거하지 않더라도 관리자(administrator)로 실행된다는 점입니다. 그 결과, 트랜잭션 활동을 확인하기 위해 시스템 노트(system notes)를 검색하면 수백 개, 심지어 수천 개의 오탐(false positives)이 발생할 수 있습니다.

사용하지 않는 역할 정리하기

시스템에 사용하지 않는 역할이 있으면 NetSuite에서 액세스 관리가 훨씬 더 어려워집니다. 다른 형태의 기술 부채와 마찬가지로, 사용 중인 역할은 액세스 제어에 관한 모든 의사결정을 더 어렵게 만듭니다. 그리고 정리(클린업) 프로젝트를 미룰수록 문제는 더 악화됩니다.

정리(클린업)의 대상이 되는 역할에는 두 가지 유형이 있습니다.

• 미할당 역할 누구에게도 할당되지 않은 역할
• 사용하지 않는 역할 할당되어 있지만 사용 중이 아닌 역할

미지정 역할을 찾으려면 직원 레코드에서 검색을 실행하고 결과를 역할별로 그룹화하기만 하면 됩니다. 목록에 없는 사용자 역할은 누구에게도 할당되어 있지 않습니다.

사용되지 않는 역할을 찾으려면 최근 6개월 동안의 모든 로그인에 대해 로그인 감사 추적(Login Audit Trail)(Setup>Manage Users>View User Login Audit Trail)을 검색하세요. 해당 목록에 역할이 없다면 사용 중이 아닙니다.

트래픽이 많은 계정에서는 이러한 검색이 시간 초과될 수 있습니다. 이 문제를 해결하려면, 관심 있는 역할만으로 검색 범위를 좁히세요.

Netwrix Strongpoint(이전: Netwrix Strongpoint)로 더 쉽게 하는 이유

Netwrix Strongpoint (formerly Netwrix Strongpoint) 는 NetSuite에서 사용되지 않는 역할과 미지정 역할을 식별하기 위한 기본 제공 검색 기능과 함께 제공됩니다.

Netwrix Strongpoint는 삭제된 역할을 영구 아카이브에 자동으로 저장하여 언제든지 복원할 수 있으므로, 한층 더 강화된 보안과 안심을 제공합니다.

앞서 언급했듯이 Netwrix Strongpoint는 특정 역할로 실행되는 스크립트를 찾아내는 유일한 솔루션입니다.

권한 사용 검토

기록이 편집될 때마다 NetSuite는 무엇이 변경되었는지, 언제 변경되었는지, 누가 어떤 역할로 변경했는지 설명하는 시스템 노트를 생성합니다. 이를 바탕으로 거슬러 올라가 어떤 권한이 데이터를 변경하는 데 사용되고 있는지 확인할 수 있습니다.

해당 기록에 시스템 노트가 있지만, 사용자가 관련 기록을 생성하거나 편집한 것과 관련된 시스템 노트가 없다면, 해당 권한은 적극적으로 사용되지 않는 것입니다(즉, 데이터를 입력하거나 데이터/설정을 변경하는 데 사용되지 않는다는 의미입니다).

다만, 현재 적극적으로 사용되고 있지 않은 권한에는 시스템 노트에 포함되지 않은 탐색(내비게이션) 요소가 있을 수 있습니다. 따라서 이 방법을 사용해 NetSuite 권한을 정리하는 경우, 식별한 후보는 View — not deleted — 로 설정하여 탐색 문제를 방지해야 합니다. 

마지막으로, 사용자 지정 역할(커스텀 역할) 그룹에서 권한을 View로 설정해야 하거나(또는 권한을 제거해야 하거나) 하는 경우에는 대량 업데이트를 사용해 해당 변경을 수행할 수 있습니다. 다만, 올바른 역할을 선택하고 있는지에 대해 아주 각별히 주의하세요.

주요 Netwrix Strongpoint 보고서:

Netwrix Strongpoint에는 권한 사용을 검토할 수 있도록 기본 제공(즉시 사용 가능) 보고서 3개가 포함되어 있습니다:

• 역할별 거래 활동: ‘역할별 거래 활동’ 보고서는 사용자 지정 거래를 포함하여 모든 거래를 다룹니다
• 역할별 회사 활동: ‘역할별 회사 활동’ 보고서는 리드(잠재고객), 고객, 잠재 고객(Prospects), 벤더, 파트너 및 기타 회사를 다룹니다.
• 기타 기록 활동(역할별): ‘기타 기록 활동(역할별)’ 보고서는 시스템 노트가 있는 모든 기록과 설정을 다룹니다.

NetSuite에 최소 권한 원칙 적용하기

데이터 보안을 확보하고 data security 무단 액세스의 위험을 최소화하려면 NetSuite 내에서 사용자 권한과 역할을 구성할 때 principle of least privilege 을 적용하는 것이 중요합니다. 사용자가 업무를 수행하는 데 필요한 최소 권한만 부여하면, 조직은 시스템 내에서의 악용 가능성과 무단 행위를 줄일 수 있습니다.

최소 권한 원칙은 사용자가 업무 책임을 효과적으로 수행하는 데 필요한 최소한의 권한만 부여할 것을 권고합니다. 특히 속도와 민첩성이 강조되는 조직의 초기 단계에서는 과도한 권한이나 역할을 할당하는 관행을 지양합니다. 불필요한 권한을 부여하면 시스템이 악용에 취약해지고 보안이 손상될 수 있습니다. 사용자 권한을 정기적으로 검토하여 현재 업무 책임과 일치하는지 확인하는 것은 필수입니다.

NetSuite에서 사용자 권한과 역할을 구성할 때는 보안 환경을 유지하기 위해 최소 권한의 원칙을 준수하는 것이 중요합니다. 다음은 몇 가지 핵심 고려 사항입니다:

1. 역할 기반 권한: 유사한 역할에 대해 권한을 일관되게 맞춰 지속적인 유지 관리가 쉽도록 합니다. 업무 기능이 유사한 사용자를 적절한 역할로 묶으면 권한 할당을 간소화하고 과도한 액세스 권한을 부여할 위험을 줄일 수 있습니다.
2. 신중한 역할 생성: 새 역할을 만들 때는 각 역할에 필요한 권한을 신중하게 평가합니다. 최소 권한의 원칙을 고려하고, 해당 역할 안에 있는 사용자들의 구체적인 업무 기능에 필요한 권한만 할당하세요.
3. 지속적인 유지 관리: 업무 책임이 변경될 때마다 사용자 권한과 역할을 정기적으로 검토하고 업데이트합니다. 이렇게 하면 사용자가 민감한 데이터나 시스템 기능에 불필요하게 액세스하지 않으면서도 업무를 효과적으로 수행하는 데 필요한 권한을 보유하도록 하는 데 도움이 됩니다.
4. 사용자 역할의 통제된 마이그레이션: NetSuite 내에서 대규모 사용자 역할 마이그레이션을 수행할 때는 수동 마이그레이션 대신 대안을 고려합니다. 오류 또는 의도치 않은 권한 상승 가능성을 최소화하면서 효율적이고 안전한 역할 전환을 가능하게 하는 옵션을 평가하세요.

업무 프로세스 리스크: 올바른 NetSuite 권한 보장

NetSuite에서 역할 권한과 권한 수준을 지정하는 것은 사용자 액세스를 제어하고 시스템 보안을 유지하는 데 매우 중요합니다. 하지만 잘못된 권한이나 부적절한 권한 수준을 부여하면 업무 프로세스 리스크가 발생할 수 있습니다. 예를 들어, 적절한 통제 없이 과도한 권한이 주어지면 사기 또는 오류로 이어질 수 있는 반면, 권한이 충분하지 않으면 재무 마감 프로세스 같은 핵심 업무를 수행하는 데 방해가 될 수 있습니다. 조직은 역할 권한을 신중하게 평가하고 최소 권한의 원칙에 맞춰 조정함으로써 리스크를 완화하고 안전한 NetSuite 환경을 보장할 수 있습니다.

NetSuite는 역할 내에서 정의할 수 있는 다양한 유형의 제한(Restriction)을 제공하여 서로 다른 유형의 레코드에 대한 액세스를 제어할 수 있습니다. 여기에는 직원 제한(Employee Restrictions), 부서 제한(Department Restrictions), 클래스 제한(Class Restrictions), 위치 제한(Location Restrictions), 자회사 제한(Subsidiary Restrictions)이 포함됩니다. 각 제한은 특정 필드 값에 따라 특정 레코드 유형에 대한 액세스를 제한함으로써, 지정된 역할을 가진 사용자가 관련 레코드만 보고 또는 편집할 수 있도록 보장합니다.

하지만 권한과 권한 수준이 올바르게 할당되지 않으면 잠재적인 업무 프로세스 리스크가 존재합니다. 예를 들어, 적절한 통제 없이 사용자 역할에 공급업체 레코드, 공급업체 청구서, 공급업체 지급을 생성할 수 있도록 허용하면 조직에 상당한 위험을 초래할 수 있습니다. 잠재적인 사기나 오류를 방지하기 위해 필요한 리스크 완화 조치를 평가하고 구현하는 것이 매우 중요합니다.

NetSuite에서 직무 분리(Segregation of Duties) 관리

직무 분리는 동일인이 동일한 거래 체인의 후속 단계를 완료할 수 있어서는 안 된다는 개념입니다. 예를 들어, 수표를 발행할 수 있으면서 동시에 은행 계좌의 잔액을 맞출 수 있는 사람이라면 사기 범행에서 흔적을 은폐할 수 있습니다.

직무 분리는 NetSuite의 역할과 권한을 검토할 때 당연히 큰 관심사입니다. 이는 SOX 준수에서 핵심적인 부분이며, 민간 기업에서도 점차 요구되고 있습니다.

직무 분리를 유지하기 위한 표준적인 방법은 서로 다른 역할을 가진 여러 사람 간에 책임을 나누는 것입니다. 또한 거래의 일부에 대해 이차 검토 또는 승인과 같은 통제 단계를 추가함으로써 달성할 수도 있습니다.

SoD를 도입할 때 기업이 가장 많이 저지르는 실수는 사용자 역할을 먼저 정리하지 않는 것입니다. 두 번째로 큰 실수는 역할 정리에 너무 몰두해 버리는 것입니다. 이를 염두에 두고, SoD를 실제로 적용(런칭)하기 위한 훨씬 더 간단한 경로를 다음과 같이 계획할 수 있습니다:

1. 사용되지 않고 할당되지 않은 모든 역할을 찾아 비활성화
2. 사용되지 않는 모든 역할 할당을 찾아 제거합니다
3. Netwrix Strongpoint의 규칙 라이브러리를 사용하여 역할 내에서 SoD 충돌 여부를 확인합니다
4. 충돌하는 권한이 실제로 사용 중인지 확인합니다. 사용 중이 아니라면 해당 권한을 “View”로 설정해 충돌을 해결하세요.
5. Netwrix Strongpoint Agent를 사용해 스마트 제어를 구성하여 남아 있는 모든 충돌을 해결합니다.
6. 다중 역할 간 충돌이 있는지 확인하고 Agent를 사용해 해결합니다.

직무 분리(SoD)는 조직 내에서 효과적인 내부 통제를 유지하고 오류와 사기를 예방하는 데 매우 중요합니다. 분리해야 할 주요 영역은 세 가지로, 권한 부여(authorization), 보관(safekeeping), 기록 관리(record-keeping)입니다.

직무 분리를 적용하면 사기 위험을 완화할 수 있습니다. 사기는 일반적으로 다음 세 가지 조건이 모두 있을 때 발생합니다: 동기(motive), 합리화(rationalization), 그리고 기회(opportunity). 공급업체 생성 및 청구서 지급, 고객 생성 및 크레딧 메모 발행, 분개 생성 및 승인과 같이 핵심 업무를 분리하면 사기를 저지를 기회가 줄어듭니다.

직무 분리는 특정 한 사람이 과도한 통제 권한을 갖고, 그 통제 권한을 무단 목적으로 남용할 수 없게 해주기 때문에 중요합니다. 이는 자금 횡령, 기업 스파이 활동, 보복 캠페인, 또는 재무 기록 조작과 같은 부정 행위를 예방하는 데 도움이 됩니다.

NetSuite의 맥락에서는 관련된 권한과 작업이 매우 다양하기 때문에, 접근을 관리하고 직무 분리를 강제하는 일이 복잡해질 수 있습니다. NetSuite에는 다양한 작업, 검색, 기록을 관장하는 수많은 권한이 포함되어 있습니다. 접근에 대한 효과적인 관리는 관리자와 재무 팀이 항상 즉시 활용할 수 있는 것은 아닐 수 있는 시간과 자원을 필요로 합니다. 또한 자동화는 감사자가 통제 결함으로 볼 수 있는 예기치 않은 충돌을 유발할 수 있어, 적절한 직무 분리를 유지하는 것이 더욱 어려워집니다.

SOX 준수 및 접근 통제

앞서 언급했듯이 SoD—그리고 일반적으로 액세스 검토—는 SOX 준수의 중요한 부분입니다. 감사자는 부정(사기) 방지 통제가 시스템에 내장되어 있고, 명확하게 정의된 역할과 권한 할당으로 뒷받침된다는 점을 확인하고 싶어 합니다.

문제는 기존의 SoD 액세스 검토가 특정 시점의 스냅샷에 불과하다는 점입니다. NetSuite 팀은 종종 막대한 비용을 들여 분기별 검토를 위해 역할과 권한을 준비합니다. 이 방식은 관련 변경 사항에 대한 광범위한 수동 검토와 오탐(오류로 판정된 항목)을 조사하는 데 수 시간의 작업이 필요합니다. 또한 이는 감사 기간 사이에 발생하는 충돌이 적발되고 조치될 것이라는 확신을 사용자—또는 감사자—에게 제공하지 못합니다.

그 결과 감사 비용은 급격히 늘어나고 스트레스 수준도 높아지며, 두 문제를 더욱 악화시키는 중대한 결함도 흔히 발생합니다. 게다가 시스템에 실제적인 보호 수단이 내장되어 있지 않기 때문에, 감사를 가까스로 통과하더라도 애초에 SOX가 목표로 하는 부정(사기)에 대해 제대로 보호받지 못합니다.

지속적 컴플라이언스 기반 액세스 관리 접근 방식

Netwrix Strongpoint는 NetSuite를 위한 유일한 기본(네이티브) SoD 솔루션입니다. SOX에 대한 당사의 ‘지속적 컴플라이언스’ 접근 방식에 기반하여, 역할 및 권한 변경 사항을 지속적으로 모니터링함으로써 언제든지 감사에 바로 활용할 수 있는 액세스 관점을 제공합니다.

Netwrix Strongpoint는 사전 승인 없이 관리자 권한을 부여하는 것처럼 특히 위험한 변경도 차단할 수 있습니다. 빠르게 구현되므로 부담을 줄이고 손쉽게 바로 적용할 수 있습니다.

사전 구축된 규칙 및 도구 라이브러리가 직원 기록에 통합되어 제공되므로, 중요 역할과 권한에 대한 접근을 통제하는 데 도움이 되는 탐지, 차단 및 완화 제어를 신속하게 구현할 수 있습니다. 또한 감사 담당자에게 이를 입증할 수 있습니다.