[转帖].NET Framework 中的传输层安全性 (TLS) 最佳做法
https://learn.microsoft.com/zh-cn/dotnet/framework/network-programming/tls
传输层安全性 (TLS) 协议是一个行业标准,旨在帮助保护通过 Internet 所传输信息的私密性。 TLS 1.2 标准与以前版本相比在安全性方面有了很多提升。 TLS 1.2 最终将被最新发布的标准 TLS 1.3 取代,后者速度更快,安全性更高。 文本介绍了如何保护使用 TLS 协议的 .NET Framework 应用程序安全的建议。
为确保 .NET Framework 应用程序的安全性,TLS 版本不应 被硬编码。 .NET Framework 应用程序应使用操作系统 (OS) 支持的 TLS 版本。
此文档面向以下开发人员:
- 直接使用 System.Net API(例如,System.Net.Http.HttpClient 和 System.Net.Security.SslStream)。
- 直接使用 WCF 客户端和使用 System.ServiceModel 命名空间的服务。
请考虑以下建议:
- 对于 TLS 1.2,在你的应用上面向 .NET Framework 4.7 或更高版本,在 WCF 应用上面向 .NET Framework 4.7.1 或更高版本。
- 对于 TLS 1.3,面向 .NET Framework 4.8 或更高版本。
- 不要指定 TLS 版本。 配置你的代码,让操作系统来决定 TLS 版本。
- 执行全面的代码审核,以验证你未指定 TLS 或 SSL 版本。
当你的应用让操作系统来选择 TLS 版本时:
- 它将会自动利用以后添加的新协议(例如 TLS 1.3)。
- 操作系统将阻止发现不安全的协议。
审核代码并对代码进行更改这一部分介绍了如何审核和更新你的代码。
本文说明了如何启用可用于应用所面向并在其上运行的 .NET Framework 版本的最强安全性。 当应用显式设置安全协议和版本时,它将选择退出任何其他替代项,并选择退出 .NET Framework 和操作系统默认行为。 如果你希望应用能够协商 TLS 1.2 连接,请显式设置为较低的 TLS 版本,以阻止 TLS 1.2 连接。
如果无法避免硬编码协议版本,我们强烈建议你指定 TLS 1.2。 有关标识和删除 TLS 1.0 依赖项的指南,请下载解决 TLS 1.0 问题白皮书。
WCF 支持 TLS1.0、1.1 和 1.2 作为 .NET Framework 4.7 中的默认设置。 从 .NET Framework 4.7.1 开始,WCF 默认为操作系统配置的版本。 如果某个应用程序使用 SslProtocols.None
显式配置,则在使用 NetTcp 传输时,WCF 将使用操作系统默认设置。
你可以在 GitHub 问题 .NET Framework 中的传输层安全性 (TLS) 最佳做法中提问有关此文档的问题。
审核代码并对代码进行更改
对于 ASP.NET 应用程序,检查 web.config 的 <system.web><httpRuntime targetFramework>
元素,以验证你所使用的是 .NET Framework 的目标版本。
有关 Windows 窗体和其他应用程序,请参阅如何:面向 .NET Framework 的某个版本。
使用以下部分验证你未使用特定 TLS 或 SSL 版本。
如果你的应用面向 .NET Framework 4.7 或更高版本
以下部分说明如何验证你未使用特定 TLS 或 SSL 版本。
对于 HTTP 网络
使用 .NET Framework 4.7 及更高版本的 ServicePointManager 将使用操作系统中配置的默认安全协议。 若要获取默认操作系统选择,如有可能,请不要设置 ServicePointManager.SecurityProtocol 属性的值,该值默认为 SecurityProtocolType.SystemDefault。
由于 SecurityProtocolType.SystemDefault 设置会导致 ServicePointManager 使用由操作系统配置的默认安全协议,因此应用程序可能会根据运行的操作系统以不同的方式运行。 例如,Windows 7 SP1 使用 TLS 1.0,而 Windows 8 和 Windows 10 使用 TLS 1.2。
针对 HTTP 网络的面向 .NET Framework 4.7 或更高版本的情况,本文剩余部分与此不相关。
对于 TCP 套接字网络
SslStream,使用 .NET Framework 4.7 和更高版本,默认为由操作系统选择最佳安全协议和版本。 若要获取默认操作系统最佳选择,如有可能,请不要使用采取显式 SslProtocols 参数的 SslStream 的方法重载。 否则,将传递 SslProtocols.None。 建议不要使用 Default;设置 SslProtocols.Default
会强制使用 SSL 3.0 /TLS 1.0,而不使用 TLS 1.2。
不要设置 SecurityProtocol 属性的值(针对 HTTP 网络)。
不要使用采取显式 SslProtocols 参数的 SslStream 的方法重载(针对 TCP 套接字网络)。 当你将应用重定向到 .NET Framework 4.7 或更高版本时,将遵循最佳做法建议。
针对 TCP 套接字网络的面向 .NET Framework 4.7 或更高版本的情况,本主题剩余部分与此不相关。
对于使用具有证书凭据的传输安全性的 WCF TCP 传输
WCF 使用与 .NET Framework 的其余部分相同的网络堆栈。
如果你面向的是 4.7.1,则 WCF 将配置为默认允许操作系统选择最佳安全协议(除非显式对其配置):
- 在你的应用程序配置文件中。
- 或者,在你的源代码中的应用程序中。
默认情况下,.NET Framework 4.7 和更高版本将配置为使用 TLS 1.2,并允许使用 TLS 1.1 或 TLS 1.0 进行连接。 通过将你的绑定配置为使用 SslProtocols.None 来配置 WCF,以允许操作系统选择最佳安全协议。 可在 SslProtocols 上进行此设置。 SslProtocols.None
可以从 Transport 中进行访问。 NetTcpSecurity.Transport
可以从 Security 中进行访问。
如果你使用自定义绑定:
- 通过将 SslProtocols 设置为使用 SslProtocols.None 来配置 WCF,以允许操作系统选择最佳安全协议。
- 或者,配置在配置路径
system.serviceModel/bindings/customBinding/binding/sslStreamSecurity:sslProtocols
中使用的协议。
如果你没有 使用自定义绑定, 且正使用配置来设置你的 WCF 绑定,则设置配置路径 system.serviceModel/bindings/netTcpBinding/binding/security/transport:sslProtocols
中使用的协议。
对于具有证书凭据的 WCF 消息安全性
默认情况下,.NET Framework 4.7 和更高版本使用 SecurityProtocol 属性中指定的协议。 当 AppContextSwitchSwitch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols
被设置为 true
时,WCF 将选择最佳协议(最高至 TLS 1.0)。
如果你的应用面向 .NET Framework 4.7 之前的版本
请使用以下部分审核代码,以验证你未设置特定 TLS 或 SSL 版本。
对于 .NET Framework 4.6 - 4.6.2(而不是 WFC)
将 DontEnableSystemDefaultTlsVersions
AppContext
开关设置为 false
。 请参阅通过 AppContext 开关配置安全性。
对于使用具有证书凭据的 TCP 传输安全性的 .NET Framework 4.6 - 4.6.2 的 WCF
必须安装最新的操作系统修补程序。 请参阅安全更新。
除非显式配置协议版本,否则 WCF 框架将自动选择高至 TLS 1.2 的最高协议。 有关详细信息,请参阅上一部分对于使用具有证书凭据的传输安全性的 WCF TCP 传输。
对于 .NET Framework 3.5 - 4.5.2(而不是 WFC)
建议将应用升级到 .NET Framework 4.7 或更高版本。 如果无法升级,请执行以下步骤:
将 SchUseStrongCrypto 和 SystemDefaultTlsVersions 注册表项设置为 1。 请参阅通过 Windows 注册表配置安全性。 .NET Framework 3.5 版本仅在传递显式 TLS 值时支持
SchUseStrongCrypto
标志。如果在 .NET Framework 3.5 上运行,则需要安装热修补程序,以便程序可以指定 TLS 1.2:
展开表KB3154518 可靠性汇总 HR-1605 - 在 Windows 7 SP1 和 Server 2008 R2 SP1 上的 .NET Framework 3.5.1 中包含对 TLS 系统默认版本的支持 KB3154519 可靠性汇总 HR-1605 - 在 Windows Server 2012 上的 .NET Framework 3.5 中包含对 TLS 系统默认版本的支持 KB3154520 可靠性汇总 HR-1605 - 在 Windows 8.1 and Windows Server 2012 R2 上的 .NET Framework 3.5 中包含对 TLS 系统默认版本的支持 KB3156421 1605 修补程序汇总 3154521 - 针对 Windows 上的 .NET Framework 4.5.2 和 4.5.1
对于使用具有证书凭据的 TCP 传输安全性的 .NET Framework 3.5 - 4.5.2 的 WCF
WCF 框架的这些版本被硬编码为使用值 SSL 3.0 和 TLS 1.0。 这些值不能更改。 必须更新和重定向到 NET Framework 4.6 或更高版本,以使用 TLS 1.1 和 TLS 1.2。
如果应用面向 .NET Framework 3.5
如果必须显式设置安全协议,而不是由 .NET 或操作系统选择安全协议,请将 SecurityProtocolTypeExtensions
和 SslProtocolsExtension
枚举添加到你的代码中。 SecurityProtocolTypeExtensions
和 SslProtocolsExtension
包含 Tls12
、Tls11
的值和 SystemDefault
值。 有关详细信息,请参阅在 Windows 8.1 和 Windows Server 2012 R2 上的 .NET Framework 3.5 中包含对 TLS 系统默认版本的支持。
通过 AppContext 开关配置安全性(适用于 .NET Framework 4.6 或更高版本)
如果你的应用面向 .NET Framework 4.6 或更高版本或在其上运行,则请关注本节中所述的 AppContext 开关。 无论它们是默认设置还是对其显式设置,开关均应为 false
(如有可能)。 如果希望通过一个或这两个开关配置安全性,则不要在你的代码中指定安全协议值,执行此操作将会替代此开关。
无论你使用 HTTP 网络 (ServicePointManager) 还是使用 TCP 套接字网络 (SslStream),开关都具有相同的效果。
Switch.System.Net.DontEnableSchUseStrongCrypto
Switch.System.Net.DontEnableSchUseStrongCrypto
的值为 false
将导致你的应用使用强加密。 DontEnableSchUseStrongCrypto
的值 false
将使用更为安全的网络协议(TLS 1.2 和 TLS 1.1),并阻止不安全的协议。 有关详细信息,请参阅 SCH_USE_STRONG_CRYPTO 标志。 值为 true
将为你的应用禁用强加密。 此交换机仅影响应用程序中的客户端(传出)连接。
如果你的应用面向 .NET Framework 4.6 或更高版本,则该开关默认为 false
。 这是我们建议使用的安全默认值。 如果你的应用在 .NET Framework 4.6 上运行,但面向早期版本,则开关默认为 true
。 在这种情况下,应显式将其设置为 false
。
如果需要连接到不支持强加密且无法升级的旧服务,则 DontEnableSchUseStrongCrypto
的值只能为 true
。
Switch.System.Net.DontEnableSystemDefaultTlsVersions
Switch.System.Net.DontEnableSystemDefaultTlsVersions
的值为 false
将导致你的应用允许操作系统选择协议。 值为 true
将导致你的应用使用由 .NET Framework 选取的协议。
如果你的应用面向 .NET Framework 4.7 或更高版本,则此开关默认为 false
。 这是我们建议使用的安全默认值。 如果你的应用在 .NET Framework 4.7 或更高版本上运行,但面向早期版本,则开关默认为 true
。 在这种情况下,应显式将其设置为 false
。
Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols
Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols
的值为 false
将导致你的应用程序使用 ServicePointManager.SecurityProtocols
中定义的值,以确保使用证书凭据的消息的安全性。 值为 true
将使用可用的最高协议(高至 TLS1.0)
对于面向 .NET Framework 4.7 和更高版本的应用程序,此值默认为 false
。 对于面向 .NET Framework 4.6.2 和早期版本的应用程序,此值默认为 true
。
Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions
Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions
的值为 false
将设置默认配置,以允许操作系统选择协议。 值为 true
会将默认值设置为可用的最高协议(高至 TLS1.2)。
对于面向 .NET Framework 4.7.1 和更高版本的应用程序,此值默认为 false
。 对于面向 .NET Framework 4.7 和早期版本的应用程序,此值默认为 true
。
有关 TLS 协议的详细信息,请参阅缓解措施:TLS 协议。 有关 AppContext
开关的详细信息,请参阅 <AppContextSwitchOverrides> Element。
通过 Windows 注册表配置安全性
警告
设置注册表项会影响系统上的所有应用程序。 仅当你完全控制计算机并可以控制对注册表的更改时才可使用此选项。
如果不能设置一个或两个 AppContext
开关,可以使用本节中所述的 Windows 注册表项来控制应用所使用的安全协议。 如果你的应用在 .NET Framework 4.5.2 或之前的版本上运行或你无法编辑配置文件,则可能无法使用一个或两个 AppContext
开关。 如果想要在注册表中配置安全性,则不要在你的代码中指定安全协议,这样做将会替代该注册表设置。
注册表项的名称类似于相应 AppContext
开关的名称,但其不带预置的 DontEnable
。 例如,AppContext
开关 DontEnableSchUseStrongCrypto
是名为 SchUseStrongCrypto 的注册表项。
这些注册表项适用于安装了最新安全修补程序的所有 .NET Framework 版本。 请参阅安全更新。
无论你使用 HTTP 网络 (ServicePointManager) 还是使用 TCP 套接字网络 (SslStream),下面介绍的所有注册表项都具有相同的效果。
SchUseStrongCrypto
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SchUseStrongCrypto
注册表项具有类型为 DWORD 的值。 值为 1 将导致你的应用使用强加密。 强加密会使用更为安全的网络协议(TLS 1.2 和 TLS 1.1),并阻止不安全的协议。 值为 0 将禁用强加密。 有关详细信息,请参阅 SCH_USE_STRONG_CRYPTO 标志。 此注册表设置仅影响应用程序中的客户端(传出)连接。
如果你的应用面向 .NET Framework 4.6 或更高版本,则此注册表项默认值为 1。 这是我们建议使用的安全默认值。 如果你的应用面向 .NET Framework 4.5.2 或更高版本,则此注册表项默认为 0。 在这种情况下,应显式将其值设置为 1。
如果需要连接到不支持强加密且无法升级的旧服务,则此注册表项的值只能为 0。
SystemDefaultTlsVersions
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SystemDefaultTlsVersions
注册表项具有类型为 DWORD 的值。 值为 1 将导致你的应用允许操作系统选择协议。 值为 0 将导致你的应用使用由 .NET Framework 选取的协议。
<VERSION>
必须为 v4.0.30319(对于 .NET Framework 4 和更高版本)或 v2.0.50727(对于 .NET Framework 3.5)。
如果你的应用面向 .NET Framework 4.7 或更高版本,则此注册表项默认值为 1。 这是我们建议使用的安全默认值。 如果你的应用面向 .NET Framework 4.6.1 或更高版本,则此注册表项默认为 0。 在这种情况下,应显式将其值设置为 1。
有关详细信息,请参阅 Windows 10 版本 1511 和 Windows Server 2016 Technical Preview 4 的累积更新:2016 年 5 月 10 日。
有关 .NET Framework 3.5.1 中的详细信息,请参阅在 Windows 7 SP1 和 Server 2008 R2 SP1 上的 .NET Framework 3.5.1 中包含对 TLS 系统默认版本的支持。
以下 .REG 文件将注册表项及其变量设置为其最安全的值:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
在 Windows 注册表中配置 Schannel 协议
可以使用注册表细化控制你的客户端和/或服务器应用协商的协议。 你的应用的网络将遍历 Schannel(它是安全通道的另一个名称)。 通过配置 Schannel
,可以配置你的应用的行为。
从 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
注册表项开始。 在该注册表项下,可以在集 SSL 2.0
、SSL 3.0
、TLS 1.1
和 TLS 1.2
中创建任何子项。 在每个子项下,可以创建子项 Client
和/或 Server
。 在 Client
和 Server
下,可创建 DWORD 值 DisabledByDefault
(0 或 1)和 Enabled
(0 或 1)。
SCH_USE_STRONG_CRYPTO 标志
启用后(默认情况下,通过 AppContext
开关或 Windows 注册表),当应用启动到服务器的 TLS 连接时,.NET Framework 将使用 SCH_USE_STRONG_CRYPTO
标志。 .NET Framework 将标志传递到 Schannel
,以指示它禁用已知弱加密算法、密码套件和 TLS/SSL 协议版本(否则,可能会启用该协议以获得更好的互操作性)。 有关详细信息,请参见:
在显式使用 SecurityProtocolType 或 SslProtocols 的 Tls11
或 Tls12
枚举值时,SCH_USE_STRONG_CRYPTO
标志还会传递到客户端(传出)连接的 Schannel
。 标志 SCH_USE_STRONG_CRYPTO
仅用于应用程序在其中充当客户端角色的连接。 当应用程序通过配置计算机范围的 Schannel
注册表设置来充当服务器角色时,你可以禁用弱协议和算法。
安全更新
本文中的最佳做法将取决于最新安装的安全更新。 这些更新包括使用高级 .NET Framework 4.7 和更高版本的功能。 如果你的应用在 .NET Framework 4.7 和更高版本上运行,则最新安全更新很重要(即使它面向早期版本)。
要更新 .NET Framework 以允许操作系统选择要使用的 TLS 的最佳版本,必须至少安装以下项:
另请参阅:
支持 TLS 1.2
为使你的应用与 TLS 1.2 协商,操作系统和 .NET Framework 版本均需支持 TLS 1.2。
支持 TLS 1.2 的操作系统要求
若要在支持它们的系统上启用或重新启用 TLS 1.2 和/或 TLS 1.1,请参阅传输层安全性 (TLS) 注册表设置。
操作系统 | TLS 1.2 支持 |
---|---|
Windows 10 Windows 2016 Server |
默认情况下支持和启用。 |
Windows 8.1 Windows Server 2012 R2 |
默认情况下支持和启用。 |
Windows 8.0 Windows Server 2012 |
默认情况下支持和启用。 |
Windows 7 SP1 Windows Server 2008 R2 SP1 |
默认情况下支持但不启用。 请参阅传输层安全性 (TLS) 注册表设置网页,以详细了解如何启用 TLS 1.2。 |
Windows Server 2008 | 支持 TLS 1.2 和 TLS 1.1 需要更新。 请参阅更新以在 Windows Server 2008 SP2 中添加对 TLS 1.1 和 TLS 1.2 的支持。 |
Windows Vista | 不支持。 |
若要详细了解在每个版本的 Windows 上默认启用的 TLS/SSL 协议,请参阅 TLS/SSL 中的协议 (Schannel SSP)。
在 .NET Framework 3.5 中支持 TLS 1.2 的要求
下表显示在 .NET Framework 3.5 中支持 TLS 1.2 所需的操作系统更新。 我们建议你应用所有操作系统更新。
操作系统 | .NET Framework 3.5 中支持 TLS 1.2 所需的最低更新 |
---|---|
Windows 10 Windows 2016 Server |
Windows 10 版本 1511 和 Windows Server 2016 Technical Preview 4 的累积更新:2016 年 5 月 10 日 |
Windows 8.1 Windows Server 2012 R2 |
在 Windows 8.1 和 Windows Server 2012 R2 上的 .NET Framework 3.5 中包含对 TLS 系统默认版本的支持 |
Windows 8.0 Windows Server 2012 |
在 Windows Server 2012 R2 上的 .NET Framework 3.5 中包含对 TLS 系统默认版本的支持 |
Windows 7 SP1 Windows Server 2008 R2 SP1 |
在 Windows 7 SP1 和 Server 2008 R2 SP1 上的 .NET Framework 3.5.1 中包含对 TLS 系统默认版本的支持 |
Windows Server 2008 | 在 Windows Vista SP2 和 Server 2008 SP2 上的 .NET Framework 2.0 SP2 中包含对 TLS 系统默认版本的支持 |
Windows Vista | 不支持 |
[转帖].NET Framework 中的传输层安全性 (TLS) 最佳做法的更多相关文章
- lync2013 错误: 已为不同的传输层安全性(TLS)目标找到类型为“McxInternal”且完全限定的域名(FQDN)为
最近 练习安装lync2013 在发布拓扑结构时遇到如下错误: lync 错误: 已为不同的传输层安全性(TLS)目标找到类型为“McxInternal”且完全限定的域名(FQDN)为“lync.co ...
- x-pack 功能介绍及配置传输层安全性(TLS / SSL)
x-pack 功能介绍及配置传输层安全性(TLS / SSL) 学习了:https://blog.csdn.net/wfs1994/article/details/80411047
- TCP/IP中的传输层协议TCP、UDP
TCP提供可靠的通信传输,而UDP则常用于让广播和细节控制交给应用的通信传输. 传输层协议根据IP数据报判断最终的接收端应用程序. TCP/IP的众多应用协议大多以客户端/服务端的形式运行.客户端是请 ...
- 在SuperSocket中启用TLS/SSL传输层加密
关键字: TLS, SSL, 传输层加密, 传输层安全, 证书使用, X509Certificate SuperSocket 支持传输层加密(TLS/SSL) SuperSocket 有自动的对TLS ...
- Self Host WebApi服务传输层SSL加密(服务器端+客户端调用)
接上篇<WebApi服务URI加密及验证的两种方式>,在实际开发中,仅对URI进行加密是不够的,在传输层采用SSL加密也是必须的. 如果服务寄宿于IIS,那对传输层加密非常简单仅需要配置一 ...
- 使用TLS/SSL传输层安全机制实现web项目的通信安全
自己的web项目在内网ip访问时,浏览器会提示不安全 原因就是因为没有证书,而传输层的TLS/SSL协议,会告诉我们本地客户端的浏览器,我现在访问的web项目的ip地址可能存在安全风险 要解决这个通信 ...
- Excel连接SSAS提示“传输层中遇到错误”的问题
用Excel连接SSAS,在身份验证时弹出对话框提示“传输层中遇到错误”,后来发现其实就是用户名或密码不对,不知道为何Excel不提示一个明确一点的信息.
- [转帖]技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解 http://www.52im.net/thread-1309-1-1.html 本文来自腾讯资深研发工程师罗成的技术分享, ...
- TCP/IP 协议图--传输层中的 TCP 和 UDP
TCP/IP 中有两个具有代表性的传输层协议,分别是 TCP 和 UDP. TCP 是面向连接的.可靠的流协议.流就是指不间断的数据结构,当应用程序采用 TCP 发送消息时,虽然可以保证发送的顺序,但 ...
- [转帖]传输层安全协议TLS 1.3 RFC 8446使互联网更快、更安全
传输层安全协议TLS 1.3 RFC 8446使互联网更快.更安全 2018-08-12 11:38:19作者:LINUX人稿源:开源社区 https://ywnz.com/linuxyffq/261 ...
随机推荐
- Fdfs上传的图片批量删除
介绍: 因为计划利用fdfs上传的图片会有很多,所以在考虑到重复利用的情况下,把半年前的图片删除掉. 1)编写清理图片脚本clear.sh 在/home/data目录下创建 clear.sh脚本 内容 ...
- ORA-28579 在从外部过程代理程序回调时,发生网络错误,ORA-06512 在"SDE.ST_GEOMETRY_SHAPELIB_PKG"
如图所示,在执行sde.st_transform方法时报错. 环境是arcgis10.8 oracle是12C,版本号是v12.1.0.2.0 但是执行ST_GEOMETRY方法是可以的,说明配置没 ...
- Spring Boot入坑-1-入坑准备&Spring简介
[写在前面] 长期做基于Spring Boot的企业应用,计划将与应用相关的技术点,通过简介.步骤.示例的方式,记录并分享出来,用于作为Spring Boot入门的记录与教程 计划的内容有: Spri ...
- SQLite3使用笔记(1)——查询
目录 1. 概述 2. 详论 2.1. 打开/关闭数据库 2.2. 数据查询 3. 参考 1. 概述 SQLite是一个嵌入式SQL数据库引擎.与大多数其他 SQL 数据库不同,SQLite 没有单独 ...
- 华为云MetaStudio全新升级,盘古数字人大模型助力数字人自由
摘要:基于盘古大模型能力,华为云MetaStudio数字内容生产线全新升级,推出数字人模型生成服务和模型驱动服务. 近日,华为开发者大会2023 ( Cloud ) 在东莞拉开帷幕.基于盘古大模型能力 ...
- 数据安全无小事:揭秘华为云GaussDB(openGauss)全密态数据库
摘要:全密态数据库,专门处理密文数据的数据库系统,数据以加密形态存储在数据库服务器中,数据库支持对密文数据的检索与计算. 1.云数据库安全现状及问题 伴随着云基础设施的快速增长和成熟,与之对应的云数据 ...
- Mock服务设计与实现:MySQL驱动字节码修改增强
摘要:华为导流测试平台通过对线上流量回放到被测环境中,利用线上真实流量进行充分测试,保证业务系统稳定上线.但是业务在导流测试过程中现网数据库往往难以同步到测试环境,导致现网数据无法正常回放,测试价值降 ...
- 学了这么久的高并发编程,连Java中的并发原子类都不知道?
摘要:保证线程安全是 Java 并发编程必须要解决的重要问题,本文和大家聊聊Java中的并发原子类,看它如何确保多线程的数据一致性. 本文分享自华为云社区<学了这么久的高并发编程,连Java中的 ...
- 乐高式扩展:在Seal软件供应链防火墙中轻松集成代码规范工具
上个月,Seal 软件供应链防火墙 v0.2(以下简称"Seal")正式发布,这一版本实现了可扩展架构,用户可以根据自身需求插件式集成原生或第三方解决方案,灵活扩展扫描能力. 在前 ...
- 最高提升10倍性能!揭秘火山引擎ByteHouse查询优化器实现方案
更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 作为企业级数据库的核心组件之一,查询优化器的地位不可忽视.对于众多依赖数据分析的现代企业来说,一个强大且完善 ...