我有以下代码连接到COBOL程序中的外部数据库:
MOVE 'I2SFG04' TO WK-USER
MOVE '12345' TO WK-PASS
EXEC SQL
CONNECT TO :WK-EXT-MACHINE
USER :WK-USER
USING :WK-PASS
END-EXEC.
但是你可以猜到,我不想硬编码用户并在COBOL程序中传递。那么有一种安全的存储方式,所以有权查看COBOL程序的人都看不到凭据吗?
我的第一种方法是使用SYSIN内容创建一个文件(受RACF保护),因此COBOL程序可以加载它,但它不会显示在源代码中。像这样:
//STEP001 EXEC PGM=IKJEFT01
//STEPLIB DD DSN=I2SJR04.SYS.DBRMLIB,DISP=SHR
//SYSIN DD DSN=EF35.PRIVATE.DB.LOGIN,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(SSID)
RUN PROGRAM(MYCOBB) PLAN(PLANNAME) -
LIB('I2SJR04.SYS.LOADLIB')
END
/*
EF35.PRIVATE.DB.LOGIN 文件的内容:
I2SFG04
12345
有没有更好的方法来处理这种情况?
答案 0 :(得分:4)
更复杂和安全的解决方案是编写一个简短的汇编程序,从安全系统(RACF,ACF2,Top Secret)本身获取用户和密码。
如果您将IBM RACF产品作为安全产品,那么这是一个叙述: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichd100/passret.htm
这种方法的作用是确定是否允许在安全管理员而不是程序员手中获取密码的逻辑。您可以向世界展示您的源代码,但如果安全系统不授予对凭据的访问权限,则用户可以看到的内容无关紧要。此外,通常可以审核此类事物,因此您可以非常轻松地获取每次引用用户/密码的完整列表。
答案 1 :(得分:2)
如果是IBM zOS大型机,则无需提供任何凭据。
您的连接将使用正在运行的作业的用户ID。
您只需告诉您的DBA该作业的JCL用户ID是什么 运行 - 然后他将授予您正在使用的计划的访问权限。
答案 2 :(得分:1)
我能看到的唯一陷阱是,如果有人在哪里重新编码并重新编译程序以输出详细信息。
所以也许您可以采取额外的步骤来使用编译程序的RACF保护程序库。
答案 3 :(得分:0)
我会尽力回答这个问题。我没有直接在COBOL中调用数据库。我们有一堆服务器程序由另一个组维护,但我确实做了一些挖掘。这就是我们使用DB2数据库的方式。我也不知道我们在幕后做了什么,所以你的里程可能会有所不同。以下是我的理解:
我们有一个JCL来执行看起来像这样的程序:
//STEP01 EXEC PGM=PGM001
//*
//*------- DB2 Plan ------------------------*
//DSNPARMS DD DSN=XX.DBNAME.DBPLAN.JOBNAME,
// DISP=(MOD,DELETE,DELETE),
// UNIT=SYSDA,
// SPACE=(TRK,(0))
//*
//INPUT (input files for job)
//OUTPUT (output files for job)
DSNPARMS文件本身为空,它用作占位符,其中包含调用数据所需的所有相关信息。文件名的结构是SystemResourceCode.DatabaseName.PlanName.JobName
根据我的理解(对于DB2数据库),所需要的只是相应地设置计划和集合,并将所有计划和集合都绑定到ACID。
所以基本上ACID与数据库集合相关联,该集合包含一组数据库计划。
数据库计划指向数据库包。简而言之,如果与您的ACID关联的集合中有适当的计划,您应该能够在没有登录凭据的情况下访问数据库,因为DBMS知道基于ACID这里是您实际可以访问的所有计划。
这也意味着需要设置TSS访问权限,以便需要访问权限的人运行具有该ACID的JCL才能运行它。
我真的没有后端的示例代码,但我希望这个解释足以让你在某处获得硬编码凭据。与数据库人员交谈,询问他们如何设置计划和收藏。他们或许可以从那里帮助你。