客户的安全和运营顾虑
强制船舶停靠港口进行检查和诊断成本高昂，而且会延缓货物交付时间。因此，客户部署了基于 CentOS 的服务器基础设施，其中包含应用程序以及远程诊断和维护工具，用于收集来自物联网传感器的数据。
维护工程师通过 AWS 云平台访问船舶。客户很快意识到，这种从公共云环境进行的关键任务访问存在风险，包括：
-
关键系统遭到破坏，包括对自动识别系统（AIS）、电子海图显示与信息系统（ECDIS）和全球海上遇险与安全系统（GMDSS）的网络攻击。这些都是至关重要的导航和通信系统，一旦遭到黑客攻击，可能导致船舶失去导航，迷失在茫茫大海中，并丧失通信能力。
-
安全问题：如果安全机制被远程关闭，受损的系统可能会造成物理损坏，从而危及船员的安全。
-
第三方访问：远程诊断通常由不同供应商的专家访问船舶系统完成。有限的跟踪、可见性和安全性可能会暴露网络威胁的入口点。
挑战 - VPN 限制
为了解决这个问题，客户尝试使用 VPN 进行远程诊断，但很快遇到了以下挑战：
-
远程访问透明度有限，无法查看会话内容。
-
与船舶网络的 VPN 连接始终处于开启状态。
-
一旦登录 VPN 服务，即可无差别访问所有区域。
-
与船舶子系统未跟踪和未识别的连接
-
共享账户和手动管理的访问凭据
-
可扩展性、连接性和性能问题
客户决定寻找一种能够满足其需求的访问解决方案，并发现了 SSH Communications Security PrivX OT。
在客户环境中，部署 PrivX OT，SSH 总代 科明大同
由于客户已经拥有一个经过深思熟虑的技术基础设施，通过亚马逊云和卫星的组合与船舶建立连接，因此部署的解决方案能够轻松融入现有基础设施至关重要。
- PrivX 与多个 IAM 和 AD 集成，以便始终将 ID 与每个会话的角色关联起来。
- PrivX 提供多种身份验证方式，包括：
-
AD/LDAP 用户名和密码
-
本地用户名和密码
-
OpenID Connect
-
多因素身份验证（TOTP 和生物识别）
-
密码/FIDO2
-
TLS客户端证书
-
SSH 公钥
-
外部 JSON Web 令牌
-
PrivX 授权器
- PrivX 存储并轮换访问所需的凭证，或启用无密码访问。凭证在使用后会被妥善保管并轮换；如果启用无密码访问，用户甚至无需查看或处理任何凭证。
- 身份验证完成后，PrivX 会自动将身份映射到正确的访问权限角色。
- 用户（维护工程师、供应商工程师、船舶技术员等）只能看到基于其角色的可用目标列表，除此之外什么也看不到。
-
用户从列表中选择目标并获取访问权限。目标可以是单个应用程序、传感器或整个服务器，具体取决于当前任务。可以根据需要限制用户可执行的操作。
借助 PrivX Extenders，可以连接到虚拟私有云 (VPC)、防火墙保护的私有网络或虚拟私有云中没有公网 IP 地址的主机。
- 所有会话都会生成审计跟踪。对于最重要的连接，提供会话录制或实时监控功能。此外，还可以要求站点管理员对关键会话进行外部授权。
- 会话结束后，用户会自动退出登录。每次会话建立时都会进行验证，以符合零信任安全框架，实现即时验证 (JIT)。