ysmox

ysmox

V2EX 第 384713 号会员,加入于 2019-02-17 22:14:26 +08:00
email: eXNtb3hzQGdtYWlsLmNvbQ==
根据 ysmox 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
ysmox 最近回复了
40 天前
回复了 030 创建的主题 宽带症候群 ZeroTier 和 Tailscale 国内打洞失败
买 HK 节点的轻量服务器吧,30Mbps
@crownor 组网设备的拥塞控制算法是不是 cubic ?如果是的话,改下 bbr 试试
@cndenis

你的业务场景其实不复杂,当前企业内部使用的系统通常都有身份认证这套系统,即“访问前登录”。但由于各种原因,内部开发的业务系统以及购买、订阅的第三方系统均无法证明足够安全。

业界通常如何解决这种问题呢?这里我讲一下我所知道的一种解决方案,即在业务系统前套一层「零信任」的网关。

先讲一下用户登录访问的流程,这里以本地用户(业务系统本身创建的用户)和 IAM 身份源举例:

- 本地用户:访问 Web->未登录重定向业务系统登录页面->登录成功进入 Web 应用。
- IAM 身份源:1. 访问 Web->2. 未登录重定向业务系统登录页面->3. 重定向至 IAM 登录页->4. 登录成功重定向到业务登录页面->5. 进入 Web 应用

注:如果不清楚 IAM 是什么的话,你可以将上面的第 3 步的 IAM 登录页理解为“微信扫码登录”、“钉钉扫码登录”、“google 登录”、“github 登录”等登录方式。

这种情况下,发布在公网的业务系统在登录前是可以被爆破的,无法确保哪些 API 不会存在漏洞。

「零信任」是怎么做的呢,简单来讲就是在业务系统前加了个「零信任网关」,用户访问业务系统均由「零信任网关」代理访问业务系统。如果你熟悉 nginx ,可以将「零信任网关」想象为一个具有身份鉴权能力的增强版 nginx 。

任何访问业务系统请求的流量,均会经过「零信任网关」,未登录的流量均会被拦截。只要当用户在「零信任」上线后,被“授权”的用户才能顺利地经过「零信任网关」访问到业务系统。这是一种关键的安全机制,它在网关层面拦截所有不可信的访问请求。

使用「零信任」后的用户访问流程:1. 访问 Web -> 2. 「零信任网关」判断请求无“身份”信息重定向至「零信任」的登录页面 -> 3. 「零信任」登录后放通请求,重定向至业务系统登录页面 -> 4. 业务系统登录成功进入 Web 。

一般人看到这里会觉得第 3 步和第 4 步都要登录,用户用起来很麻烦需要登录两次,但绝大部分情况下只需要登录一次,怎么做到的呢?这里我讲两种常用的方案:

1. 上面提到过的 IAM 身份源,如果「零信任」和业务系统的身份源都是同一个 IAM 系统,那么登录一次后,当用户访问其他业务系统时,会重定向跳转至 IAM 页面,此时会自动完成登录再回到登录后的业务系统页面。例如:我们访问 A 服务用的是 google 的身份,第一次需要登录 google 账号,后面访问 B 服务、C 服务等,若业务系统本身默认使用 google 账号登录,那么访问时便自动完成这个登录动作。

2. 对业务系统进行简单改造,用「零信任」的身份登录系统。什么意思呢?当第 3 步完成后,用户已经成功上线「零信任」系统了,此时用户访问业务系统,业务系统本身并不知道当前用户是谁,但业务系统可以去请求「零信任」拿到身份信息,完成用户上线。

以上两种方案本质上其实是同一种,对于用户而言它只需要登陆一次即可,当然厂家提供的登录方式不止于此。

「零信任」是个理念,上述是「零信任」的一种实现、一种解决方案。

至于你问的有没有成熟好用的产品推荐,并且满足体制内的安全要求(例如等保、信创)。在网络安全厂商里是可以找到相应的「零信任」解决方案的,尤其是国内头部的网络安全厂商如“深信服”、“奇安信”,又或者其他互联网大厂,你可以直接联系他们了解更多。
其实前面有不少朋友都提到了“零信任”甚至“oauth2-proxy”,但只是提及个名词就作罢,实质上核心都是“访问控制”。

传统的 VPN 打通了局域网与内网,但如果 ACL (访问控制列表)没做好,一旦工作人员的设备被侵入,公司内网将面临危机,对于入侵者而言就是一览无余。

「零信任」的核心理念就是八个字:“永不信任、持续验证”。在业界,厂商的简单实现通常就是做好“访问控制”。

站在应用角度,主要分为以下两种应用场景:

- Web 代理应用:“编辑想在公司外访问内容管理平台”,如果「内容管理平台」是一个 Web 应用,那么只需在 Web 应用前面的网关加上“认证”机制。当公网上访问 URL 时,未登录用户无访问权限,将被重定向到登录页面;登录后才能访问「内容管理平台」。这解决了「零信任」中的一种场景。

- 隧道应用:这种场景是将应用隐藏在公司防火墙后面,不对外暴露服务。通常的解决方式是安装厂商提供的客户端(适用于 Windows 、Mac 、Linux 、Android 、iOS ),用户登录后,设备只会和“被授权”的内网应用建立隧道连接。这样,只有授权的人才能知道内网应用的存在并访问到。因为这需要建立隧道才能访问,没有登录的人自然无法发现「内容管理平台」,即使登录了没有权限也是一样,这也是「零信任」能解决的另一种场景。

综上所述,对于暴露在公网的 Web 应用,我们应只允许“授权用户”访问,并通过网关为当前会话连接赋予“身份”;对于不想暴露在公网的应用,就像传统 VPN 一样,使用隧道技术,只允许与“授权应用”建立连接,当然要比传统的 VPN 做得更好。

类似 oauth2-proxy 、authelia 这样的开源组件,都是不错的解决方案,但不一定能提供最佳体验。例如,如果有一个 docs 应用隐藏在 authelia 的网关之后,未登录的用户会被重定向到 authelia 的登录页面,但由于 authelia 目前仅支持账号密码、LDAP 方式登录,并不支持主流的 OAuth2.0 、OIDC ,因此在公司层面可能难以推广,这毕竟只是一个开源项目。

当然还有很多其他方面值得注意,但先就这样吧。
362 天前
回复了 nvksie 创建的主题 Linux 有用 amd 7840h + Linux 的小伙伴吗?
```bash
root@pve:~# lscpu | grep 'Model name' | head -n 1
Model name: AMD Ryzen 7 7840H w/ Radeon 780M Graphics
root@pve:~# hostnamectl
Static hostname: pve
Icon name: computer-desktop
Chassis: desktop 🖥️
Machine ID: e620797c076246c7b272dc75ae9f7xxx
Boot ID: 78782e567beb448a8e611af600d63xxx
Operating System: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.2.16-3-pve
Architecture: x86-64
Hardware Vendor: Machenike
Hardware Model: Machenike DT Computer
Firmware Version: 101
root@pve:~# uptime
01:55:42 up 27 days, 16:02, 2 users, load average: 0.08, 0.16, 0.17
root@pve:~# date -R
Mon, 06 Nov 2023 01:55:47 +0800
```

不用新特性的话,没必要用那么新的内核
2023-03-11 19:05:09 +08:00
回复了 const 创建的主题 NAS 局域网内群晖连接问题求教
可以
arXiv 平台的存在就是解决 idea 和数据被剽窃的问题。

arXiv 是由康奈尔大学运营维护的一个非盈利的数据库,由于免费,学术研究人员可以在其他顶会或者期刊没有录用之前,将自己最新的研究成果发布到该平台上,一方面是为了扩大宣传提升自己的影响力;另外一方面是为了保护自己的科研成果,因为无论会议和期刊从投出到最终可以检索,都需要长时间的等待,很难保证期间自己成果不被别人剽窃,arXiv 可以证明论文的原创性。——来源:某乎
@yiXu 我本人!
2020-08-06 16:37:51 +08:00
回复了 faustina2018 创建的主题 分享发现 88vip 支持网易云音乐年会员兑换了…
@liuribi NTgyODAxMTg3QHFxLmNvbQ== 谢谢老哥
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2642 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 9ms · UTC 12:18 · PVG 20:18 · LAX 05:18 · JFK 08:18
Developed with CodeLauncher
♥ Do have faith in what you're doing.