我正在评估使用不同的 Oracle 模式与单独的 Oracle 服务器的优缺点。为每个应用程序配备一个专用服务器确实很昂贵，如果安全优势值得，我只想考虑这一点。
主要的症结之一是 SQL 注入的主题。如果应用程序 A 的 SQL 注入破坏了 Oracle 数据库中模式 A 中的所有数据，那么攻击者是否也可以访问模式 B 中的数据（在同一个 Oracle 数据库中）？
我倾向于认为除了最关键的数据存储之外，通过模式进行分离就足够了。这是最佳实践吗？要考虑的主要因素是什么？
通过 Oracle 模式从不同应用程序中分离数据是否被认为是安全的？
信息安全
sql注入
甲骨文
2021-08-17 05:04:03
2个回答
为每个应用程序创建特定的数据库用户是一个常见的概念。这些用户应该拥有完成工作所需的最低权限。
让我们将此应用于您的示例：
- ApplicationA使用DataBaseUserA，它具有在 SchemaA 中读取/插入/更新/删除 TableA 的权限。
- ApplicationB使用DataBaseUserB，它有权读取 SchemaB 中的 TableB。
- 当然，您还至少有一个 DBA 帐户。
现在考虑 ApplicationB 易受 SQL 注入攻击：
- select * from SchemaA.TableA由 DataBaseUserB 注入和执行。
- 数据库响应将是ORA-00942：表或视图不存在
在大多数用例中，我认为这种行为足够安全。当然，如果 Oracle DB 中出现一些未知的安全关键问题，完全不同的数据库实例会增加另一层安全性。
在您描述的场景中，如果架构 A 遭到破坏——除非 Oracle 本身存在一些未知漏洞——它只能访问架构 B 中的数据，前提是 B 的权限已与 A 共享。
如果不清楚，假设您在 Schema B 中拥有TABLE1and TABLE2。现在假设您在 Schema B 中执行以下命令：
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA_B.TABLE1 TO SCHEMA_A;
那么，如果模式 A 被破坏，TABLE1就有风险，但TABLE2应该是安全的。
如果您改为在 Schema B 中执行以下命令：
GRANT SELECT ON SCHEMA_B.TABLE1 TO SCHEMA_A;
那么你的风险就会降低（但没有消除）：渗透模式 A 的邪恶者可以看到数据（TABLE1这仍然可能非常糟糕，取决于那里的内容）——但应该无法更改数据。
现在回到我用斜体表示的那一点：（“除非 Oracle 本身存在一些未知漏洞”）：许多引起巨大悲痛的漏洞都是从特定应用程序的未知漏洞开始的。如果您有幸分离服务器（考虑到服务器费用、维护时间和费用、当前和未来直接共享数据的需求），那么您可以为数据提供的隔离越多，它就越安全。