访问控制

前几天在帮后端排查一个cors的问题的时候发现的一些小坑特此记录 ** cors的本质是出于安全原因，浏览器限制从脚本内发起的跨源HTTP请求。 例如，XMLHttpRequest和Fetch API遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源，除非使用CORS头文件。 跨域并非一定是浏览器限制了跨站请求，也有可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击原理，请求是发送到了后端服务器无论是否跨域！注意：有些浏览器不允许从 HTTPS 的域跨域访问 HTTP，比如 Chrome 和 Firefox，这些浏览器在请求还未发出的时候就会拦截请求。 ** 本case场景描述如下： 用户在a.com域名下跨域访问b.com域名下的api接口，使用了XMLHttpRequest的跨域头请求。域名b.com也允许了可以跨域 Access-Control-Allow-Origin 但是很奇怪在访问b.com的接口时有些api能访问成功，有些api访问失败。排查发现访问失败的api都是需要用户的登录态的。但是用户已经在b.com登录过了。把XMLHttpRequest请求换成jsonp请求则都可以请求成功(这好像是废话)。。。由此推测XMLHttpRequest 添加cors头的时候没有把b.com的

微服务刚刚诞生的时候，人们将服务进行拆分，实现服务之间的松耦合，并且每个服务有专门的团队维护，然后客户端直接和各个子服务进行交互。比如，订单，商品，会员服务。 那么这种客户端直接和后端服务交互的方式会有什么问题呢？ 1、客户端需要知道每个服务的地址 2、每个后端服务都需要实现认证、限流、日志、监控、缓存等功能，重复造轮子大大降低了开发效率，而这些公共业务逻辑完全可以拆分出来 3、假如后端某些服务由之前的http/https调用变成rpc调用，或者某些参数发生改变，则客户端需要做很大调整。 后来人们为了解决这些问题，引入 API网关 。 当引入API网关后，API网关接管了所有的入口流量，就像nginx，将请求路由到对应的后端服务。这样客户端无需关心后端服务地址，只需调用网关即可。不仅如此，网关还针对这些流量做了功能的扩展，包括鉴权、限流、日志监控、告警、访问控制、协议转换等功能，这样后端服务只需关注自身的业务逻辑。 我们可以将API网关的部分功能做一个简单的梳理。 注册API API网关要给后端服务赋能，就需要后端服务（API提供者）将API信息注册到网关，并且为每个API配置后端服务的地址。但是，这样遇到的问题是，API之间是独立的，无法将服务于同一功能的API组织起来，统一管理。为了适应真实的服务场景，API网关使用API分组来管理一组API，并配置同一后端，用户（API提供者

1、选择交换机的主要技能指标是什么？ （1）机架插槽数：指机架式交换机所能安插的最大模块数。 （2）扩展槽数：指固定配置式带扩展槽交换机所能安插的最大模块数。 （3）最大可堆叠数：指可堆叠交换机的堆叠单元中所能堆叠的最大交换机数目。 （4）支持的网络类型：一般情况下，固定配置式不带扩展槽交换机仅支持一种类型的网络，机架式交换机和固定配置式带扩展槽交换机可支持一种以上类型的网络，如支持以太网、快速以太网、千兆以太网、ATM、令牌环、FDDI等。一台交换机所支持的网络类型越多，其可用性和可扩展性将越强。 （5）最大SONET端口数：SONET（Synchronous Optical Network，同步传输网络）是一种高速同步传输网络规范，最大速率可达2.5Gbit/s。一台交换机的最大SONET端口数是指这台交换机的最大下传的SONET接口数。 （6）背板吞吐量：背板吞吐量也称背板带宽，单位是每秒通过的数据包个数（pps），表示交换机接口处理器或接口卡和数据总线间所能吞吐的最大数据量。一台交换机的背板带宽越高，所能处理数据的能力就越强，但同时成本也将会越高。 （7）MAC地址表大小：连接到局域网上的每个端口或设备都需要一个MAC地址，其他设备要用到此地址来定位特定的端口及更新路由表和数据结构。一个设备MAC地址表的大小反映了该设备能支持的最大节点数。 （8）支持的协议和标准

通过网站访问控制功能，可以对终端用户访问网站进行管控，可以设置网站访问黑白名单，只允许用户访问某些网站或禁止访问某些网站；支持设置网页关键词，涉及到关键词的网页禁止打开。 选择 网络管理 分组，点击 网站访问控制 按钮， 新建策略 ，点击左侧 生效时间 标签，可以设置全天还是自定义时间段，可以设置3个自定义时间段。 选择左侧 网址管控 标签，可以对终端访问的网址进行控制，勾选开启策略，选择黑名单或白名单，选择生效网站，Ping32系统内置常见类型的网址，管理者可以直接勾选。 如果想禁止的网址在网址库中没有的话，可以点击“+”按钮，自定义添加网址。 如果管理者想通过关键词来拦截终端访问的网站，选择 内容拦截 标签，填写关键词。比如填写了“股票”，那么终端用户浏览的网站中设计到“股票”的将全部禁止访问，终端将无法访问股票类的网站。设置完后选择生效策略。 新建策略后，可以通过右侧策略设置面板进行设置，启用或停用策略，重新选择生效终端，设置策略参数操作。若不需要此策略，点击左上方删除策略按钮进行删除。 通过设置终端网站访问控制，终端将不能访问某些网站，直接打消了终端用户上班时间娱乐等行为的念头，无奈下只能继续工作，这样一来就管控了员工的上网行为和提高了员工工作效率。 来源： 51CTO 作者： liguangxing0220 链接： https://blog.51cto.com

原文地址： Role-based access control 总览 身份验证已添加到etcd 2.1中。 etcd v3 API略微修改了身份验证功能的API和用户界面，以更好地适应新的数据模型。本指南旨在帮助用户在etcd v3中设置基本身份验证和基于角色的访问控制。 特殊用户和角色 有一个特殊用户 root ，一个特殊角色 root 。 用户 root 在激活身份验证之前，必须创建对 etcd 具有完全访问权限的 root 用户。 root 用户的想法是出于管理目的：管理角色和普通用户。 root 用户必须具有 root 角色，并且可以在 etcd 中进行任何更改。 角色 root 可以将角色 root 授予除 root 用户之外的任何用户。 具有 root 角色的用户既具有全局读写访问权限，又具有更新集群的身份验证配置的权限。 此外， root 角色授予常规集群维护的特权，包括修改集群成员资格，对存储进行碎片整理以及拍摄快照。 用户的工作方式 etcdctl 的 user 子命令处理与用户帐户有关的所有事情。 可以通过以下方式找到用户列表： $ etcdctl user list 通过以下方式创建新用户： $ etcdctl user add myusername 创建新用户将提示您输入新密码。 当给出选项 --interactive=false 时

Tomcat访问控制 注意：测试功能，生产环境不要用 tomcat管理功能用于对tomcat自身以及部署在tomcat上的应用进行管理的web应用。 在默认情况下是处于禁用状态的，如果需要开启这个功能，就需要配置管理用户，即配置、 tomcat-users.xml文件。 ~~~~~~~~实验如下：主机：192.168.200.67 [root@localhost ~]# java -version openjdk version "1.8.0_131" OpenJDK Runtime Environment (build 1.8.0_131-b12) OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) [root@localhost ~]# tar xf apache-tomcat-8.5.40.tar.gz [root@localhost ~]# ls anaconda-ks.cfg 公共 下载 apache-tomcat-8.5.40 模板 音乐 apache-tomcat-8.5.40.tar.gz 视频 桌面 initial-setup-ks.cfg 图片 original-ks.cfg 文档 [root@localhost ~]# mv apache-tomcat-8.5.40 /usr/local

资料 网址 什么是访问控制 https://help.aliyun.com/document_detail/28672.html?spm=5176.11065259.1996646101.searchclickresult.1aec5812vc1t0S&aly_as=peBT0Zk1 多因素认证（Multi-factor authentication，MFA） https://help.aliyun.com/document_detail/28635.html?spm=a2c4g.11186623.6.687.4b3d688awlcL5e 来源： https://www.cnblogs.com/cag2050/p/11887949.html

MongoDB 3.0+安全权限访问控制 --------------------没有安全认证时，进行用户权限的管理-------------------- 1、启动没有访问控制的MongoDB服务 sudo service mongod start 2、连接到实例 mongo --port 27017 指定额外的命令行选项来连接Mongo shell到部署Mongodb服务器, 如--host 3、创建的用户管理员 use admin db.createUser( { user: "myUserAdmin", pwd: "abc123", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } ) 4、重新启动MongoDB实例，并启用访问控制 1、重新启动mongod实例，如果使用配置文件的设置，security.authorization： vi /etc/mongod.conf 修改内容： security: authorization: enabled 2、注意：keys and values之间一定要加空格, 否则解析会报错 重启服务： sudo service mongod start 5、用户管理员身份验证 1、创建连接mongo shell 时进行授权，指定-u <username>, -p

身份认证技术 1、常用的身份认证方法 （1）静态口令认证的问题：静态口令，即由用户自己设置或者系统给定的一串静态数据作为口令。静态口令一旦设定之后，除非用户更改，否则将保持不变。这种方法存在严重的安全问题。 基于口令认证的安全性仅仅基于用户口令的保密性，如果用户口令较短且容易猜测，那么这种方案就容易遭受口令猜测攻击。 如果口令在通信线路上明文传输，系统攻击者就能够通过窃听方法获取用户口令。 由于系统需要保存用户名和口令，这一方面要求系统管理员是可信赖的，另一方面，一旦攻击者能够访问口令库，整个系统的安全性就受到了威胁，如果口令库中保存明文的口令，那么攻击者就能够直接获取用户口令；如果保存的是经过密码变换后的口令，例如保存口令的 HASH 值，攻击者也可以采用离线方式对口令密文实施字典攻击或穷举攻击，从而获得合法用户的口令。 静态口令对重放攻击也毫无抵抗能力。 （2）一次性口令认证：一次性口令认证技术通常是基于密码技术来实现，通过在认证过程中加入不确定因子、认证数据传输过程加密等方式，使用户每次进行身份认证的认证口令都不同，而且每个认证口令只使用一次，攻击者即使获得了某次登录的认证口令也无法在下一次成功登录到系统，因为攻击者获得的登录口令已经失效。为了产生一次性的动态口令，一般采用双运算因子的计算方式，也就是加密算法的输入包括两个数值，一个是用户密钥，通常是代表用户身份的识别码

防火墙-NAT NAT地址转换 工作在网络层和传输层，实现地址重写 作用： 隐藏本地网路中主机地址 节约IP地址的使用 分类 SNAT：只是修改请求报文的源地址，一般用于代理内网中的客户机访问外网 DNAT：只是修改请求报文的目标地址，一般用于代理服务端接收客户请求 iptables中的nat表用于实现nat功能 NAT表的三个链： PREROUTING （DNAT实现的位置） OUTPUT POSTROTING （SNAT实现的位置） SNAT配置 iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j SNAT --to-source 192.168.20.254 #本机作为网关，配置SNAT代理内网主机访问外网 #192.168.10.0/24 匹配到需要代理的内网网段 #-j SNAT --to-source 192.168.20.254 将源地址替换为指定的外网IP #-t nat -A POSTROUTING 源地址替换需要在nat表中的POSTROUTING链上执行 #SNAT可以指定单个ip作为替换，也可以是多个ip，但必须给定作为源地址替换的ip 若外网IP为动态获取可以使用MASQUERADE地址伪装策略 iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j