Как избежать жесткого кодирования учетных данных в программе COBOL?

Question

У меня есть следующий код для подключения к внешней БД внутри программы 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, не мог видеть учетные данные?

Моим первым подходом было создание файла (защищенного RACF) с содержимым SYSIN, чтобы программа 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

Есть ли лучший способ справиться с подобными ситуациями?

Answer 1

Более сложным и безопасным решением было бы написание короткой ассемблерной программы, которая извлекает пользователя и пароль из самой системы безопасности (RACF, ACF2, Top Secret).

Вот краткое описание, если у вас есть продукт IBM RACF в качестве продукта безопасности: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichd100/passret.htm

То, что делает этот подход, заключается в том, чтобы разрешить выбор пароля в руки администратора безопасности, а не программиста. Вы можете показать миру свой исходный код, но если система безопасности не предоставляет доступ к учетным данным, не имеет значения, что может видеть пользователь. Кроме того, такие вещи обычно можно проверять, поэтому вы можете довольно легко получить полный список при каждом обращении к пользователю / паролю.

Answer 2

Я постараюсь ответить на это.Я не работал напрямую с вызовом базы данных в 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 здесь находятся все планы, к которым у вас есть доступ.

Это также означает, что доступ к TSS должен быть настроен так, чтобы любой, кому нужен доступ для запуска JCL с этим ACID, мог его запустить.

У меня нет образцакод бэкэнда, но я надеюсь, что этого объяснения было достаточно, чтобы где-то пройти через учетные данные жесткого кода.Поговорите с ребятами из базы данных и спросите их о настройке планов и коллекций.Они могут помочь вам оттуда.

Answer 3

Если это мэйнфрейм IBM zOS, вам не нужно указывать учетные данные.

Ваше соединение будет использовать идентификатор пользователя запущенного задания.

Вам просто нужно сообщить своему администратору базы данных, какой идентификатор пользователя JCL будет работать запустить под - он тогда предоставит доступ к плану, который вы используете.

Answer 4

Единственный подводный камень, который я вижу, это если кто-то, где перекодировать и перекомпилировать программу, скажет, что выводит детали.

Так что, возможно, вы могли бы сделать дополнительный шаг использования библиотеки программ, защищенной RACF, в которую компилируется программа.