데이터 보호

데이터 보안은 애플리케이션 생성에서 가장 중요하지만 간과되는 측면 중 하나입니다. ServiceNow는 테이블 생성 프로세스 중에 새 역할 또는 선택한 역할에 대한 접근 제어를 자동으로 구성합니다. 해당 역할이 있는 사용자만 테이블에 액세스하여 읽기, 생성, 쓰기 및 삭제할 수 있습니다.

접근 제어 규칙을 사용하여 Now Platform에서 테이블 및 열 수준의 보안을 구성합니다. 애플리케이션에 대한 액세스를 올바르게 구성하려면 개발자는 접근 제어가 작동하는 방식과 접근 제어가 평가되는 순서를 이해해야 합니다. 여러 접근 제어를 적용하여 ACL(접근 제어 목록)을 만듭니다.

자기 주도형 교육: 애플리케이션 보안

문서: 접근 제어 목록 규칙

보안을 고려할 때:

• 적절한 접근 제어 및 역할로 테이블, UI 페이지, 속성 페이지 및 기타 콘텐츠를 보호합니다.
• 접근 제어 스크립트에서 GlideRecord 쿼리의 사용을 제한합니다. GlideRecord 쿼리는 성능에 영향을 줄 수 있습니다.

Orlando 플랫폼 구독 모델부터는 사용자의 액세스 여부와 관계없이 사용자가 액세스할 수 있는 테이블 수에 따라 요금이 부과됩니다. 테이블에 대한 액세스가 필요한 사용자만 테이블에 액세스할 수 있도록 테이블에 대한 액세스를 제한하도록 ACL을 구성합니다.

주:

자동으로 채워진 필드를 읽기 전용으로 설정하는 것이 좋습니다. 시스템이 데이터를 채우는 경우 사용자는 이 작업을 수행할 수 없어야 합니다.

또는 쿼리 전 비즈니스 규칙을 사용하여 Now Platform에서 데이터를 보호합니다. 쿼리 전 비즈니스 규칙은 데이터베이스 쿼리 전에 실행되며 기록에 대한 읽기 액세스 제어로 제한됩니다. 필요한 경우에만 쿼리 전 비즈니스 규칙을 사용합니다. 접근 제어 또는 쿼리 전 비즈니스 규칙을 사용하기로 결정할 때 고려해야 할 사항은 다음과 같습니다.

• GlideRecord 쿼리는 테이블에서 읽기 접근 제어를 바이패스하며 테이블의 쿼리 전 비즈니스 규칙으로 제한됩니다.
• 접근 제어가 목록의 기록에 대한 읽기 액세스를 제한하면 ServiceNow는 기록에 대한 접근이 제한되었다는 메시지를 표시합니다. 쿼리 전 비즈니스 규칙을 사용하면 목록의 총 기록 수가 사용자에게 표시되는 기록 수와 일치합니다. 사용자는 일부 기록이 목록에서 숨겨졌다는 어떠한 표시도 받지 못합니다.

참조를 위해 사용자 [sys_user] 테이블에서 사용자 쿼리 비즈니스 규칙을 검토합니다.

주:

쿼리 전 비즈니스 규칙이 ACL을 대신하지 않습니다. 사전 쿼리 비즈니스 규칙을 통해 테이블에 대한 사용자 접근을 거부하면 여전히 구독 모델에 대해 테이블이 계산됩니다. 접근 제어를 사용하여 플랫폼 구독 모델의 사용자에 대해 테이블이 계산되지 않도록 합니다.

암호화

또한 Now Platform은 애플리케이션 계층, 데이터베이스 계층 및 하드웨어 계층에서 다양한 암호화 솔루션을 제공합니다. 데이터 암호화 백서에서 자세히 알아보십시오.

주:

인터페이스 또는 비즈니스 논리를 구성하기 전에 보안을 설정합니다. 보안은 인터페이스 및 비즈니스 논리에서 사용할 수 있는 데이터에 영향을 주므로 애플리케이션 빌드 프로세스가 끝날 때까지 기다리면 재작업과 문제가 발생할 수 있습니다.