デフォルトのアクセス制御監査ツールスイートで利用可能なチェック、それらで評価される基準、およびそれらを使用してインスタンスのセキュリティを向上させる方法について説明します。

アクセス制御リスト (ACL) のルールは、まず要件のセットをユーザーに要求し、その後でユーザーとやり取りできるようにすることで、データへのアクセスを制限します。アクセス制御監査ツールのチェックでは、次の表に示す 8 つのクライテリアに従ってインスタンスが評価されます。これらのチェックの結果を使用して、インスタンスのセキュリティを向上させます。

表 : 1. アクセス制御監査ツールのチェック

チェック名	チェッククライテリア	説明
タイプ - SCRIPT のすべてのプロセッサは CSRF トークンで保護する必要があります	CSRF トークンで保護されていない SCRIPT タイプのプロセッサをチェックします。	SCRIPT タイプのすべてのプロセッサは、クロスサイト要求偽造 (CSRF) トークンで保護する必要があります。これらのプロセッサでは、CSRF オプションをオンにする必要があります。これにより、インスタンスが CSRF トークンを使用しない限り、プロセッサーの実行が禁止されます。
ナレッジごとに定義する、寄稿可能/寄稿不可ユーザーのクライテリア	[寄稿可能] または [寄稿不可] のユーザー基準が定義されていないナレッジベースレコードをチェックします。	各ナレッジベースには、[寄稿可能] または [寄稿不可] のユーザー基準を定義する必要があります。定義しないと、どのユーザーも、寄稿基準が定義されていないナレッジベースにコンテンツを寄稿できてしまいます。
空の ACL	セキュリティ属性、ロール、または public ロールを持たないアクセス制御リスト (ACL) レコードをチェックします。	ACL を空のままにするか、public ロールを使用すると、この ACL で保護されているすべてのコンテンツへのオープンアクセスが提供される可能性があります。
クライアントコール可能スクリプトインクルードのアクセス制御	ACL で保護されていないクライアント呼び出し可能スクリプトインクルードをチェックします。	すべてのクライアント呼び出し可能スクリプトインクルードは、必要なロールを使用して ACL で保護する必要があります。
UI ページのアクセス制御	ACL で保護されていない UI ページがないかチェックします。	UI ページへのアクセスを保護する ACL がない場合、ログインしているすべての内部ユーザーがその UI ページにアクセスできます。制限がなければ、ログインユーザーが許可されていない変更を行う可能性があります。
テーブルでのアクセス制御	ACL のないテーブルをチェックします。	テーブルは ACL で保護する必要があります。テーブルに格納されているデータへのアクセスは、それを必要とするユーザーのみに制限する必要があります。
ユーザーアカウントに内部ロールと外部ロールの両方を設定することはできません	内部ロールと外部ロールの両方がアサインされているユーザーレコードがないかチェックします。	内部ユーザーロールは、社内のユーザーを対象としています。外部ユーザーロールは、顧客やパートナーなどの外部担当者を対象としています。
誰でもアクセス可能なナレッジベースと記事	誰でもアクセス可能なナレッジベースとナレッジベース記事がないかチェックします。	誰でもアクセス可能なナレッジベースと記事は、インスタンス内のすべてのユーザーに表示されます。ナレッジベースと記事を、それらを必要とする特定の対象者に制限することで、セキュリティを強化します。