安全なデータ

データセキュリティは、アプリケーションを作成する上で最も重要でありながら見落とされがちな要素の 1 つです。ServiceNow は、テーブルの作成プロセス中に、新規のロールまたは選択されたロールのアクセス制御を自動的に構成します。ロールを持つユーザーのみが、テーブルにアクセスして読み取り、作成、書き込み、削除を行うことができます。

Now Platform では、アクセス制御ルールを使用して、テーブルレベルおよび列レベルのセキュリティを構成します。アプリケーションへのアクセスを適切に構成するために、開発者は、アクセス制御の仕組みとアクセス制御が評価される順序を理解する必要があります。複数のアクセス制御を適用し、それらを組み合わせてアクセス制御リスト (ACL) が構成されます。

自分のペースで進められるトレーニング：Securing Applications (アプリケーションの保護)

ドキュメント：アクセス制御リストのルール

セキュリティを考慮するタイミング：

• 適切なアクセス制御とロールを使用して、テーブル、UI ページ、プロパティページ、およびその他のコンテンツを保護します。
• アクセス制御スクリプトでの GlideRecord クエリの使用を制限します。GlideRecord クエリはパフォーマンスに影響を与える可能性があります。

Orlando Platform Subscription モデル以降、ユーザーがテーブルにアクセスするかどうかに関係なく、ユーザーがアクセスできるテーブルの数によって顧客に課金されます。テーブルへのアクセスを制限するように ACL を構成し、テーブルへのアクセスを必要とするユーザーのみがテーブルにアクセスできるようにします。

注:

自動入力されるフィールドを読み取り専用にすることを検討してください。システムによってデータが入力されている場合、ユーザーは入力できません。

または、クエリ前ビジネスルールを使用して、Now Platform 上のデータを保護します。クエリ前ビジネスルールは、データベースクエリの前に実行され、レコードへの読み取りアクセスの制御に制限されます。必要な場合にのみ、クエリ前ビジネスルールを使用します。アクセス制御またはクエリ前ビジネスルールの使用を決定する際の考慮事項：

• GlideRecord クエリは、テーブルの読み取りアクセス制御をバイパスし、テーブルのクエリ前ビジネスルールによって制限されます。
• アクセス制御によってリスト内のレコードへの読み取りアクセスが制限されている場合、ServiceNow では、レコードのアクセスが制限されていることを示すメッセージが表示されます。クエリ前ビジネスルールでは、リストの合計レコード数は、ユーザーに表示されるレコードの数と一致します。一部のレコードがリストで非表示になったとき、ユーザーはそのことを示す通知を受け取りません。

参照用に、ユーザー [sys_user] テーブルのユーザークエリビジネスルールを確認してください。

注:

クエリ前ビジネスルールは ACL の代わりにはなりません。クエリ前ビジネスルールを使用してユーザーのテーブルへのアクセスを拒否しても、サブスクリプションモデルに対してテーブルがカウントされます。プラットフォームサブスクリプションモデルのユーザーに対してテーブルがカウントされないようにするには、アクセス制御を使用します。

暗号化

Now Platform は、アプリケーション層、データベース層、およびハードウェア層でさまざまな暗号化ソリューションも提供します。詳細については、データ暗号化に関するホワイトペーパーを参照してください。

注:

インターフェイスまたはビジネスロジックを構成する前に、セキュリティを設定します。セキュリティはインターフェイスやビジネスロジックで利用可能なデータに影響するため、アプリケーション構築プロセスを終了するまで待つと、やり直しや問題が発生する可能性があります。