2同行回答
API网关通常都支持通过安全策略定义的方式（security policy)来进行API安全访问控制，常用的安全策略包括身份认证、授权，有的还把报文的安全性（数字签名、加解密）作为安全访问控制的一部分。常用的认证授权方式包括APPKey/APP Secret, 以及OAuth。在API的描述标准Swagger中有专门的security部分。好的API平台都能支持Swagger security 所能描述的标准。
API系统提供的企业级安全防护能力通常包括：
• 基于角色的访问控制（Role Based Access Control ，RBAC），在每一层实行“职责分离”，并保护敏感信息，包括API密钥，SSL证书，OAuth的令牌和审计日志等;
• 采用开放标准如OAuth, SAML 和LDAP的APIs，用户，开发人员，系统管理员的身份认证;
• 通过OAuth Token, APP Key 和RBAC策略来进行 细粒度授权管理；
• 利用SSL/TLS来保护通讯链路层的安全；
• 利用日志，监控和审计进行安全分析；
• 对XML, JSON, 和DoS攻击防护。
访问控制可分为自主访问控制和强制访问控制两大类。
自主访问控制，是指由用户有权对自身所创建的访问对象（文件、数据表等）进行访问，并可将对这些对象的访问权授予其他用户和从授予权限的用户收回其访问权限。
强制访问控制，是指由系统（通过专门设置的系统安全员）对用户所创建的对象进行统一的强制性控制，按照规定的规则决定哪些用户可以对哪些对象进行什么样操作系统类型的访问，即使是创建者用户，在创建一个对象后，也可能无权访问该对象。
基于对象的访问控制模型
基于对象的访问控制（OBAC Model：Object-based Access Control Model）：DAC或MAC模型的主要任务都是对系统中的访问主体和受控对象进行一维的权限管理。当用户数量多、处理的信息数据量巨大时，用户权限的管理任务将变得十分繁重且难以维护，这就降低了系统的安全性和可靠性。
对于海量的数据和差异较大的数据类型，需要用专门的系统和专门的人员加以处理，要是采用RBAC模型的话，安全管理员除了维护用户和角色的关联关系外，还需要将庞大的信息资源访问权限赋予有限个角色。
当信息资源的种类增加或减少时，安全管理员必须更新所有角色的访问权限设置，如果受控对象的属性发生变化，和需要将受控对象不同属性的数据分配给不同的访问主体处理时，安全管理员将不得不增加新的角色，并且还必须更新原来所有角色的访问权限设置以及访问主体的角色分配设置。
这样的访问控制需求变化往往是不可预知的，造成访问控制管理的难度和工作量巨大。所以在这种情况下，有必要引入基于受控对象的访问控制模型。
控制策略和控制规则是OBAC访问控制系统的核心所在，在基于受控对象的访问控制模型中，将访问控制列表与受控对象或受控对象的属性相关联，并将访问控制选项设计成为用户、组或角色及其对应权限的集合；同时允许对策略和规则进行重用、继承和派生操作。
这样，不仅可以对受控对象本身进行访问控制，受控对象的属性也可以进行访问控制，而且派生对象可以继承父对象的访问控制设置，这对于信息量巨大、信息内容更新变化频繁的管理信息系统非常有益，可以减轻由于信息资源的派生、演化和重组等带来的分配、设定角色权限等的工作量。
OBAC访问控制系统是从信息系统的数据差异变化和用户需求出发，有效地解决了信息数据量大、数据种类繁多、数据更新变化频繁的大型管理信息系统的安全管理。并从受控对象的角度出发，将访问主体的访问权限直接与受控对象相关联，一方面定义对象的访问控制列表，增、删、修改访问控制项易于操作，另一方面，当受控对象的属性发生改变，或者受控对象发生继承和派生行为时，无须更新访问主体的权限，只需要修改受控对象的相应访问控制项即可，从而减少了访问主体的权限管理，降低了授权数据管理的复杂性。
基于任务的访问控制模型
基于任务的访问控制模型（TBAC Model，Task-based Access Control Model）是从应用和企业层角度来解决安全问题，以面向任务的观点，从任务（活动）的角度来建立安全模型和实现安全机制，在任务处理的过程中提供动态实时的安全管理。
在TBAC中，对象的访问权限控制并不是静止不变的，而是随着执行任务的上下文环境发生变化。TBAC首要考虑的是在工作流的环境中对信息的保护问题：在工作流环境中，数据的处理与上一次的处理相关联，相应的访问控制也如此，因而TBAC是一种上下文相关的访问控制模型。其次，TBAC不仅能对不同工作流实行不同的访问控制策略，而且还能对同一工作流的不同任务实例实行不同的访问控制策略。从这个意义上说，TBAC是基于任务的，这也表明，TBAC是一种基于实例（instance-based）的访问控制模型。
TBAC模型由工作流、授权结构体、受托人集、许可集四部分组成。
任务（task）是工作流程中的一个逻辑单元，是一个可区分的动作，与多个用户相关，也可能包括几个子任务。授权结构体是任务在计算机中进行控制的一个实例。任务中的子任务，对应于授权结构体中的授权步。
授权结构体（authorization unit）：是由一个或多个授权步组成的结构体，它们在逻辑上是联系在一起的。授权结构体分为一般授权结构体和原子授权结构体。一般授权结构体内的授权步依次执行，原子授权结构体内部的每个授权步紧密联系，其中任何一个授权步失败都会导致整个结构体的失败。
授权步（authorization step）表示一个原始授权处理步，是指在一个工作流程中对处理对象的一次处理过程。授权步是访问控制所能控制的最小单元，由受托人集（trustee-set）和多个许可集（permissions set）组成。
受托人集是可被授予执行授权步的用户的集合，许可集则是受托集的成员被授予授权步时拥有的访问许可。当授权步初始化以后，一个来自受托人集中的成员将被授予授权步，我们称这个受托人为授权步的执行委托者，该受托人执行授权步过程中所需许可的集合称为执行者许可集。授权步之间或授权结构体之间的相互关系称为依赖（dependency），依赖反映了基于任务的访问控制的原则。授权步的状态变化一般自我管理，依据执行的条件而自动变迁状态，但有时也可以由管理员进行调配。
一个工作流的业务流程由多个任务构成。而一个任务对应于一个授权结构体，每个授权结构体由特定的授权步组成。授权结构体之间以及授权步之间通过依赖关系联系在一起。在TBAC中，一个授权步的处理可以决定后续授权步对处理对象的操作许可，上述许可集合称为激活许可集。执行者许可集和激活许可集一起称为授权步的保护态。
TBAC模型一般用五元组（S，O，P，L，AS）来表示，其中S表示主体，O表示客体，P表示许可，L表示生命期（lifecycle），AS表示授权步。由于任务都是有时效性的，所以在基于任务的访问控制中，用户对于授予他的权限的使用也是有时效性的。
因此，若P是授权步AS所激活的权限，那么L则是授权步AS的存活期限。在授权步AS被激活之前，它的保护态是无效的，其中包含的许可不可使用。当授权步AS被触发时，它的委托执行者开始拥有执行者许可集中的权限，同时它的生命期开始倒记时。在生命期期间，五元组（S，O，P，L，AS）有效。生命期终止时，五元组（S，O，P，L，AS）无效，委托执行者所拥有的权限被回收。
TBAC的访问政策及其内部组件关系一般由系统管理员直接配置。通过授权步的动态权限管理，TBAC支持最小特权原则和最小泄漏原则，在执行任务时只给用户分配所需的权限，未执行任务或任务终止后用户不再拥有所分配的权限；而且在执行任务过程中，当某一权限不再使用时，授权步自动将该权限回收；另外，对于敏感的任务需要不同的用户执行，这可通过授权步之间的分权依赖实现。
TBAC从工作流中的任务角度建模，可以依据任务和任务状态的不同，对权限进行动态管理。因此，TBAC非常适合分布式计算和多点访问控制的信息处理控制以及在工作流、分布式处理和事务管理系统中的决策制定。
基于角色的访问控制模型
基于角色的访问控制模型（RBAC Model，Role-based Access Model）：RBAC模型的基本思想是将访问许可权分配给一定的角色，用户通过饰演不同的角色获得角色所拥有的访问许可权。这是因为在很多实际应用中，用户并不是可以访问的客体信息资源的所有者（这些信息属于企业或公司），这样的话，访问控制应该基于员工的职务而不是基于员工在哪个组或是谁信息的所有者，即访问控制是由各个用户在部门中所担任的角色来确定的，例如，一个学校可以有教工、老师、学生和其他管理人员等角色。
RBAC从控制主体的角度出发，根据管理中相对稳定的职权和责任来划分角色，将访问权限与角色相联系，这点与传统的MAC和DAC将权限直接授予用户的方式不同；通过给用户分配合适的角色，让用户与访问权限相联系。角色成为访问控制中访问主体和受控对象之间的一座桥梁。
角色可以看作是一组操作的集合，不同的角色具有不同的操作集，这些操作集由系统管理员分配给角色。在下面的实例中，我们假设Tch1，Tch2，Tch3……Tchi是对应的教师，Stud1，Stud 2，Stud3 …Studj是相应的学生，Mng1，Mng 2，Mng 3…Mngk是教务处管理人员，那么老师的权限为TchMN={查询成绩、上传所教课程的成绩}；学生的权限为Stud MN={查询成绩、反映意见}；教务管理人员的权限为MngMN={查询、修改成绩、打印成绩清单}。
那么，依据角色的不同，每个主体只能执行自己所制定的访问功能。用户在一定的部门中具有一定的角色，其所执行的操作与其所扮演的角色的职能相匹配，这正是基于角色的访问控制（RBAC）的根本特征，即：依据RBAC策略，系统定义了各种角色，每种角色可以完成一定的职能，不同的用户根据其职能和责任被赋予相应的角色，一旦某个用户成为某角色的成员，则此用户可以完成该角色所具有的职能。
如今数据安全成疾，蠕虫和病毒横行，如何提高网络安全？选择网络访问控制（NAC）成为必然，它能够帮助企业网络免于多种网络安全威胁。[1]
许多企业往往不愿意实施基于角色的访问控制。因为企业担心冗长而复杂的实施过程，并且由于雇员访问权要发生变化，也会对工作效率带来副作用。完成基于角色的矩阵可能是一个需要花费企业几年时间的复杂过程。
有一些新方法可以缩短这个过程，并当即带来好处。企业可以采用人力资源系统作为数据源，收集所有雇员的部门、职位、位置以及企业的层次结构等信息，并将这些信息用于创建每个访问级别的角色。下一步就是从活动目录等位置获得当前的权利，以及与不同角色的雇员有关的数据共享。
实现机制
访问控制的实现机制建立访问控制模型和实现访问控制都是抽象和复杂的行为，实现访问的控制不仅要保证授权用户使用的权限与其所拥有的权限对应，制止非授权用户的非授权行为；还要保证敏感信息的交叉感染。为了便于讨论这一问题，我们以文件的访问控制为例对访问控制的实现做具体说明。通常用户访问信息资源（文件或是数据库），可能的行为有读、写和管理。为方便起见，我们用Read或是R表示读操作，Write或是W表示写操作，Own或是O表示管理操作。我们之所以将管理操作从读写中分离出来，是因为管理员也许会对控制规则本身或是文件的属性等做修改，也就是修改我们在下面提到的访问控制表。
访问控制表
访问控制表（ACLs：Access Control Lists）是以文件为中心建立的访问权限表，简记为ACLs。目前，大多数PC、服务器和主机都使用ACLs作为访问控制的实现机制。访问控制表的优点在于实现简单，任何得到授权的主体都可以有一个访问表，例如授权用户A1的访问控制规则存储在文件File1中，A1的访问规则可以由A1下面的权限表ACLsA1来确定，权限表限定了用户UserA1的访问权限。
访问控制矩阵
访问控制矩阵（ACM：Access Control Matrix）是通过矩阵形式表示访问控制规则和授权用户权限的方法；也就是说，对每个主体而言，都拥有对哪些客体的哪些访问权限；而对客体而言，又有哪些主体对他可以实施访问；将这种关连关系加以阐述，就形成了控制矩阵。其中，特权用户或特权用户组可以修改主体的访问控制权限。访问控制矩阵的实现很易于理解，但是查找和实现起来有一定的难度，而且，如果用户和文件系统要管理的文件很多，那么控制矩阵将会成几何级数增长，这样对于增长的矩阵而言，会有大量的空余空间。
访问控制能力列表
能力是访问控制中的一个重要概念，它是指请求访问的发起者所拥有的一个有效标签（ticket），它授权标签表明的持有者可以按照何种访问方式访问特定的客体。访问控制能力表（ACCLs：Access Control Capabilitis Lists）是以用户为中心建立访问权限表。例如，访问控制权限表ACCLsF1表明了授权用户UserA对文件File1的访问权限，UserAF表明了UserA对文件系统的访问控制规则集。因此，ACCLs的实现与ACLs正好相反。定义能力的重要作用在于能力的特殊性，如果赋予哪个主体具有一种能力，事实上是说明了这个主体具有了一定对应的权限。能力的实现有两种方式，传递的和不可传递的。一些能力可以由主体传递给其他主体使用，另一些则不能。能力的传递牵扯到了授权的实现，我们在后面会具体阐述访问控制的授权管理。
安全标签
安全标签是限制和附属在主体或客体上的一组安全属性信息。安全标签的含义比能力更为广泛和严格，因为它实际上还建立了一个严格的安全等级集合。访问控制标签列表（ACSLLs： Access Control Security Labels Lists）是限定一个用户对一个客体目标访问的安全属性集合。安全标签能对敏感信息加以区分，这样就可以对用户和客体资源强制执行安全策略，因此，强制访问控制经常会用到这种实现机制。