데이터 보호

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

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

자율 학습식 교육: 애플리케이션 보안

설명서: 접근 제어 목록 규칙

보안을 고려하는 경우:

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

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

주:

자동으로 채워진 필드를 읽기 전용으로 설정하는 것이 좋습니다. 시스템에서 데이터를 채우는 경우 사용자는 데이터를 채울 수 없습니다.

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

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

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

주:

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

암호화

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

주:

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