访问控制概述
以下主题介绍访问控制策略。
访问控制规则和默认操作
使用访问控制策略允许或阻止对网络资源的访问。该策略包含一系列有序的规则，按从上到下的顺序进行评估。对流量应用的规则是符合所有流量条件标准的第一个规则。
您可以根据以下条件控制访问：
-
传统网络特征，例如源和目的 IP 地址、协议、端口和接口（以安全区形式）。
-
源或目标（以网络对象形式）的完全限定域名 (FQDN)。流量匹配基于从 DNS 查询为该名称返回的 IP 地址。
-
正在使用的应用。您可以基于特定应用控制访问，也可以创建涵盖应用类别、标记特定特征的应用、应用类型（客户端、服务器、Web）或应用风险或业务相关性评级的规则。
-
Web 请求的目的 URL，包括 URL 的通用类别。您可以基于目标站点的公共信誉优化类别匹配。
-
发出请求的用户或用户所属的用户组。
对于您允许的未加密流量，可以应用 IPS 检测来检查威胁并阻止看似攻击的流量。另外，您还可以使用文件策略来检查是否存在禁止文件或恶意软件。
与访问规则不匹配的流量由访问控制默认操作处理。默认情况下，如果允许流量，则可以对流量应用入侵检测。但您不能对默认操作处理的流量执行文件或恶意软件检测。
应用过滤
您可以使用访问控制规则基于连接中使用的应用过滤流量。系统会识别各种各样的应用，因此您不需要弄明白如何在不阻止所有 Web 应用的情况下阻止某个 Web 应用。
对于一些常用的应用，您可以根据应用的不同方面进行过滤。例如，您可以创建一个阻止 Facebook 游戏但不阻止所有 Facebook 功能的规则。
您还可以基于一般应用特点创建规则，通过选择风险或业务关联性、类型、类别或标记来阻止或允许整组应用。但是，在应用过滤器中选择类别时，请查看匹配的应用列表，确保不包含非预期应用。有关可能分组的详细说明，请参阅应用条件。
已加密和已解密流量的应用控制
如果应用使用加密，系统可能无法识别该应用。
系统可以检测使用 StartTLS 加密的应用流量，包括 SMTPS、POP、FTPS、TelnetS 和 IMAPS。此外，系统还可以根据 TLS ClientHello 消息中的服务器名称指示或服务器证书中的主题专有名称值来识别某些加密应用。
请使用应用过滤器对话框通过选择以下标记来确定应用是否需要解密，然后检查应用列表。
-
SSL 协议 - 不需要解密标记为 “SSL 协议” 的流量。系统可以识别此流量并应用您的访问控制操作。用于所列出应用的访问控制规则应与预期的连接匹配。
-
解密流量 - 只有先解密流量，系统才能识别此流量。配置用于此流量的 SSL 解密规则。
应用过滤最佳实践
设计应用过滤访问控制规则时，请牢记以下建议。
-
要处理网络服务器所推荐的流量（例如广告流量），请匹配被推荐的应用（而非推荐应用）。
-
避免将应用与 URL 标准组合在同一规则中，尤其是对于加密流量。
-
如果要为标记为解密流量的流量编写规则，请确保具有解密匹配流量的 SSL 解密规则。仅可在解密连接中识别这些应用。
-
系统可以检测多个类型的 Skype 应用流量。要控制 Skype 流量，请从应用过滤器列表中选择 Skype 标记（而不是选择个别应用）。这确保系统可以相同方式检测和控制所有 Skype 流量。
-
要控制 Zoho 邮件访问，请选择 Zoho 和 Zoho 邮件应用。
URL 过滤
您可以使用访问控制规则基于 HTTP 或 HTTPS 连接中使用的 URL 过滤流量。请注意，HTTP 的 URL 过滤比 HTTPS 更直接，因为 HTTPS 会被加密。
您可以使用以下方法实施 URL 过滤：
-
基于类别和信誉的 URL 过滤 - 使用 URL 过滤许可证，您可以根据 URL 的一般分类（类别）和风险级别（信誉）控制对网站的访问。这是迄今为止阻止非必要网站的最简单、最有效的方法。
-
手动 URL 过滤 - 使用任何许可证均可手动指定各个 URL 和 URL 组，以便对网络流量实现精细的自定义控制。手动过滤的主要目的是创建基于类别的阻止规则的例外，但可以将手动规则用于其他目的。
以下主题提供了有关 URL 过滤的详细信息。
按照类别和信誉过滤 URL
通过 URL 过滤许可证，您可以基于所请求 URL 的类别和信誉控制对网站的访问：
-
类别 - URL 的一般分类。例如，ebay.com 属于“拍卖”类别，而 monster.com 属于“职位搜索”类别。URL 可以属于多个类别。
-
信誉 - URL 被用于可能违反组织安全策略之目的的可能性。范围可从“高风险”（第 1 级）到“知名”（第 5 级）。
URL 类别和信誉可帮助您快速配置 URL 过滤。例如，您可以使用访问规则阻止“滥用药物”类别中的高风险 URL。
使用类别和信誉数据还会简化策略创建和管理。代表安全威胁的站点或提供不良内容的站点的出现和消失速度，可能比您更新和部署新策略的速度要快。由于思科使用新站点、已更改分类与信誉更新 URL 数据库，因此，规则会自动调整以适应新信息。无需为新站点编辑规则。
如果启用常规 URL 数据库更新，则可确保系统使用最新信息进行 URL 过滤。还可启用与思科综合安全情报 (CSI) 的通信，获取类别和信誉已知的 URL 的最新威胁情报。有关详细信息，请参阅配置URL 过滤首选项。
 注 |
要查看事件和应用详细信息中的 URL 类别和信誉信息，必须至少创建一条具有 URL 标准的规则。 |
查找 URL 的类别和信誉
您可以通过以下网站检查特定 URL 的类别和信誉。您可以使用此信息，帮助您查看基于类别和信誉的 URL 过滤规则的表现。
手动 URL 过滤
您可以通过手动过滤各个 URL 或 URL 组，补充或选择性地覆盖基于类别和信誉的 URL 过滤。您可以在没有特殊许可证的情况下执行此类 URL 过滤。
例如，您可以使用访问控制阻止不适合于您组织的某类网站。但是，如果该类别包含适合的网站，且要为其提供访问权限，则可以为该站点创建手动“允许”规则，并将该规则置于适用于该类别的“阻止”规则前。
要配置手动 URL 过滤，请使用目标 URL 创建一个 URL 对象。基于如下规则解释该 URL：
-
如果不包含路径（即 URL 中无 / 字符），则匹配仅基于服务器主机名。如果主机名位于 :// 分隔符之后，或在主机名中的任何点之后，则认为该主机名匹配。例如，ign.com 匹配 ign.com 和 www.ign.com，但不匹配 verisign.com。
-
如果包含一个或多个 / 字符，则整个 URL 字符串将用于子字符串匹配，其中包括服务器名称、路径和任何查询参数。但是，我们建议您不要使用手动 URL 过滤阻止或允许个别网页或部分网站，因为这样可能会重组服务器并将页面移至新路径。子字符串匹配还可能导致意外匹配，其中 URL 对象中包含的字符串也与非预期服务器上的路径或查询参数中的字符串匹配。
-
系统忽略加密协议（HTTP 与 HTTPS）。换句话说，如果阻止网站，系统将阻止发往该网站的 HTTP 和 HTTPS 流量，除非您使用一个应用条件指定特定协议。在创建 URL 对象时，您不需要指定创建对象时的协议。例如，使用 example.com 而不是 http://example.com。
-
如果您计划使用 URL 对象匹配访问控制规则中的 HTTPS 流量，请使用加密流量时所使用的公钥中的主题公用名创建该对象。此外，系统会忽略在主题公用名中的子域，因此，不包括子域信息。例如，使用 example.com 而不是 www.example.com。
但请注意，证书中的使用者公用名可能与网站的域名完全无关。例如，youtube.com 证书中的使用者公用名是 *.google.com（当然，这可能会随时更改）。如果使用 SSL 解密策略解密 HTTPS 流量以便 URL 过滤规则可用于解密策略，则可能获得更一致的结果。
注
如果由于证书信息不再可用，浏览器恢复 TLS 会话，则 URL 对象将不匹配 HTTPS 流量。因此，即使精心配置 URL 对象，也可能会得到不一致的 HTTPS 连接结果。
过滤 HTTPS 流量
由于 HTTPS 流量加密，所以直接对 HTTPS 流量执行 URL 过滤并不像对 HTTP 流量执行 URL 过滤那样直接。因此，应考虑使用 SSL 解密策略解密想要过滤的所有 HTTPS 流量。这样，URL 过滤访问控制策略可有效用于解密流量，并会获得与常规 HTTP 流量相同的结果。
但是，如果打算允许某些 HTTPS 流量在未加密情况下通过访问控制策略，则需了解规则匹配 HTTPS 流量与匹配 HTTP 流量的方式不同。要过滤加密流量，系统将根据 SSL 握手期间传递的信息确定请求的 URL：用于加密流量的公钥证书中的主题公用名称。URL 中的网站主机名与使用者公用名之间可能没有多大关系。
HTTPS 过滤与 HTTP 过滤不同，它不考虑使用者公用名内的子域。手动过滤 HTTPS URL 时，请勿包含子域信息。例如，使用 example.com 而不是 www.example.com。此外，请查看站点所使用的证书内容，以确保使用者公用名中使用的域名正确，且该名称不会与其他规则冲突（例如，想要阻止的站点名称可能与想要允许的站点名称重叠）。例如，youtube.com 证书中的使用者公用名是 *.google.com（当然，这可能会随时更改）。
注 |
如果由于证书信息不再可用，浏览器恢复 TLS 会话，则 URL 对象将不匹配 HTTPS 流量。因此，即使精心配置 URL 对象，也可能会得到不一致的 HTTPS 连接结果。 |
按加密协议控制流量
在执行 URL 过滤时，系统会忽略加密协议（HTTP 和 HTTPS）。对于手动 URL 标准和基于信誉的 URL 标准均会发生此情况。换句话说，URL 过滤以相同方式处理发送到以下网站的流量：
-
http://example.com
-
https://example.com
要配置仅匹配 HTTP 流量或 HTTPS 流量（而不是同时匹配这两种流量）的规则，请在“目标”条件中指定 TCP 端口或在规则中添加应用条件。例如，可以通过构造两个访问控制规则（各规则具有 TCP 端口或应用和 URL 标准）来允许对某个站点进行 HTTP 访问，同时禁止 HTTP 访问。
第一个规则允许 HTTPS 流量到达网站：
- 操作：允许
- TCP 端口或应用：HTTPS（TCP 端口 443）
- URL：example.com
第二个规则阻止对同一网站进行 HTTP 访问：
- 操作：阻止
- TCP 端口或应用：HTTP（TCP 端口 80）
- URL：example.com
比较 URL 和应用过滤
URL 和应用过滤具有许多相似之处。但应将其用于明显不同的目的：
-
URL 过滤最好用于阻止或允许访问整个 Web 服务器。例如，如果不希望在网络上进行任何类型的赌博，则可创建用于阻止赌博类别的 URL 过滤规则。通过该规则，用户无法访问该类别内所有 Web 服务器上的任何页面。
-
应用过滤适用于阻止特定应用（无论托管站点如何），或阻止在其他方面受允许的其他网站的特定功能。例如，可以在不阻止所有 Facebook 功能的情况下阻止 Facebook 游戏应用。
由于组合应用与 URL 标准可能会导致非预期结果，尤其是对于加密流量，因此，分别创建用于 URL 和应用标准的单独规则是个好方法。如果需要将应用与 URL 标准合并到单个规则中，应将这些规则直接置于仅应用或仅 URL 规则后，除非应用+URL 规则作为更一般的仅应用或仅 URL 规则的例外。由于 URL 过滤阻止规则比应用过滤阻止规则更广泛，因此，您应将其置于仅应用规则之上。
如果将应用标准与 URL 标准组合在一起，则可能需要更仔细地监控网络，以确保不允许访问不必要的站点和应用。
有效 URL 过滤的最佳实践
设计 URL 过滤访问控制规则时，请牢记以下建议。
-
尽可能使用类别和信誉阻止。这可以确保在将新站点添加到类别时自动将其阻止，且如果站点的信誉变得更佳（或更劣），则根据信誉对阻止情况进行调整。
-
使用 URL 类别匹配时，请注意，有时候站点登录页的类别与站点本身的类别不同。例如，Gmail 属于“基于 Web 的邮件”类别，而登录页面属于互联网门户类别。如果您为类别制定了包含不同操作的不同规则，可能会出现意想不到的结果。
-
使用 URL 对象定位整个网站，并对类别阻止规则进行例外处理。也就是说，允许特定网站（否则，该网站会被阻止于某个类别规则中）。
-
如果要手动阻止 Web 服务器（使用 URL 对象），则在安全情报策略中这样做更有效。评估访问控制规则前，安全情报策略丢弃连接，以便可获得更快、更有效的阻止。
-
为对 HTTPS 连接进行最有效的过滤，请使用 SSL 解密规则解密正在为其编写访问控制规则的流量。任何解密的 HTTPS 连接均会在访问控制策略中作为 HTTP 连接予以过滤，以避免 HTTPS 过滤的所有限制。
-
将 URL 阻止规则置于任何应用过滤规则前，因为 URL 过滤阻止整个 Web 服务器，而应用过滤将针对特定的应用使用，而不考虑 Web 服务器。
阻止网站时用户看到的内容
使用 URL 过滤规则阻止网站时，用户所看到的内容视该站点是否加密而异。
-
HTTP 连接 - 用户会看到系统默认阻止响应页面，而不是为超时或重置连接而正常显示的浏览器页面。此页面将明确指示，您有意阻止了该连接。
-
HTTPS（已加密）连接 - 用户不会看到系统默认阻止响应页面。相反，用户会看到浏览器显示安全连接故障的默认页面。错误消息不会指明该站点由于策略而被阻止。相反，错误可能显示为没有通用的加密算法。据此消息，无法明确看出是您有意阻止了该连接。
此外，网站可能是被属于非明示 URL 过滤规则的其他访问控制规则，甚至是被默认操作而阻止。例如，如果阻止整个网络或地理位置，也会阻止该网络或该地理位置的任何网站。受这些规则阻止的用户可能（也可能不能）得到以下限制中所述的响应页面。
如果实施 URL 过滤，请考虑向最终用户说明他们在站点被有意阻止时可能会看到的内容，以及您将阻止的站点类型。否则，他们可能会花费大量时间来解决受阻止的连接故障。
HTTP 响应页面的限制
当系统阻止网络流量时，并不总是显示 HTTP 响应页面。
-
如果网络流量由于提升的访问控制规则（放在前面的仅包含简单网络条件的阻止规则）被阻止，系统则不显示响应页面。
-
如果网络流量在系统识别请求的 URL 之前被阻止，则系统不显示响应页面。
-
对于被访问控制规则阻止的已加密连接，系统不会显示响应页面。
入侵、文件和恶意软件检测
入侵策略和文件策略共同发挥作用，作为允许流量到达其目的地之前的最后一道防线。
-
入侵策略监管系统的入侵防御功能。
-
文件策略监管系统的文件控制和适用于 Firepower 的 AMP 功能。
处理所有其他流量后，才会检验网络流量中是否存在入侵、禁止文件和恶意软件。通过将入侵策略或文件策略与访问控制规则相关联，您是在告诉系统：在其传递符合访问控制规则条件的流量之前，您首先想要使用入侵策略和/或文件策略检测流量。
您只能对允许流量的规则配置入侵策略和文件策略。对于设置为信任或阻止流量的规则，系统不会执行检测。此外，如果访问控制策略的默认操作是允许，则您可以配置入侵策略，但不能配置文件策略。
对由访问控制规则处理的任何单个连接，文件检测均发生在入侵检测之前。也就是说，系统不检测文件策略所阻止的文件是否存在入侵。在文件检测中，基于类型的简单阻止优先于恶意软件检测和阻止。文件在会话中得以检测和阻止之前，来自该会话的数据包均可能接受入侵检测。
注 |
默认情况下，系统禁用对已加密负载的入侵和文件检查。当已加密连接与已配置入侵和文件检查的访问控制规则相匹配时，这有助于减少误报和提高性能。检测仅适用于未加密的流量。 |
访问控制规则顺序最佳实践
先匹配的规则先应用，所以您必须确保流量匹配条件标准较具体的规则显示在次之用来匹配流量的较通用条件标准的策略上方。请考虑以下建议：
-
特定规则应在一般规则之前，特别当特定规则是一般规则的例外时。
-
仅基于第 3/4 层标准丢弃流量的任何规则（如 IP 地址、安全区域和端口号）应尽早出现。我们建议这些规则应在需要检查的任何规则前，如具有应用或 URL 标准的规则，因为可快速评估第 3/4 层标准而无需检查。当然，这些规则的任何例外必须置于这些规则之上。
-
尽可能将特定丢弃规则置于策略顶部附近。这确保了对非预期流量尽可能做出最早的决定。
-
包括应用和 URL 标准的任何规则应直接位于仅应用或仅 URL 规则前，除非应用+URL 规则作为更一般仅应用或仅 URL 规则的例外。组合应用和 URL 标准可能会导致非预期结果，尤其是对于加密流量，因此，我们建议您尽可能创建单独的 URL 和应用过滤规则。
NAT 和访问规则
在确定访问规则匹配时，访问规则始终将使用真实 IP 地址，即使您已配置 NAT。例如，如果已为内部服务器 (10.1.1.5) 配置 NAT，以使该服务器在外部拥有公共可路由的 IP 地址 209.165.201.5，则用于允许外部流量访问内部服务器的访问规则需要引用该服务器的真实 IP 地址 (10.1.1.5)，而非映射地址 (209.165.201.5)。
其他安全策略如何影响访问控制
其他安全策略可能影响访问控制规则的运行和对连接的匹配。配置访问规则时，请记住以下几点：
-
SSL 解密策略 - 访问控制前评估 SSL 解密规则。因此，如果加密连接与应用某类型解密的 SSL 解密规则相匹配，则该连接为通过访问控制策略评估的纯文本（解密）连接。访问规则无法查看加密版本的连接。此外，访问控制策略绝不会看到任何与丢弃流量的 SSL 解密规则相匹配的连接。最后，匹配“不解密”规则的任何加密连接将以其加密状态接受评估。
-
身份策略 - 仅当存在用于源 IP 地址的用户映射时，连接才与用户（以及用户组）匹配。侧重于用户或组成员关系的访问规则可能仅匹配身份策略成功收集的用户身份的那些连接。
-
安全情报策略 - 访问控制策略绝不会看到任何被列入黑名单和丢弃的连接。
-
VPN（站点间或远程访问）- 始终根据访问控制策略对 VPN 流量进行评估，并根据匹配规则允许或丢弃连接。但在评估访问控制策略前，VPN 隧道本身将被解密。访问控制策略评估嵌入 VPN 隧道中的连接，而不是隧道本身。
反馈