Как не раскрывать учетные данные производственной БД другим разработчикам?

В приложении PHP, которое я пишу, я бы не хотел раскрывать учетные данные производственной БД другим разработчикам.

Я прочитал здесь несколько вопросов и ответов о SO, например в следующей ветке есть много интересных мыслей по теме:

Как защитить пароли к базе данных в PHP?

Я решил, что хочу переместить учетные данные в файле за пределы корня приложения. Предположим, что я использую PDO и в своем контейнере приложения я создаю свой экземпляр PDO:

<?php

// ...
require_once __DIR__ . '/../db_pdo_outside_document_root.php';

$containerConfig = [
   'db_connection' => function() {
      return new PDO(DB_PDO_DSN, DB_PDO_USER, DB_PDO_PASSWD, DB_PDO_OPTIONS);
   }
];
$appContainer = new ApplicationContainer($containerConfig);

// Use the container and handle the request...

Все константы DB_PDO_*, переданные конструктору PDO, происходят из файла db_pdo_outside_document_root.php, который находится вне корня документа:

<?php
// db_pdo_outside_document_root.php
define('DB_PDO_DSN', 'mysql:host=localhost;dbname=app_database');
define('DB_PDO_USER', 'db_user');
define('DB_PDO_PASSWD', 'db_fancy_passwd');
define('DB_PDO_OPTIONS', [
    PDO::ATTR_PERSISTENT => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);

Все идет нормально. Однако это мало помогает, потому что, если кто-то захочет повторить содержимое констант, он может легко это сделать:

<?php

// In some PHP file used by the application... 

echo DB_PDO_PASSWD; // echoes the DB password.
//mail('[email protected]', 'Subject', DB_PDO_PASSWD); // Or send it by email

Сейчас, конечно, нужно доверять коллегам, с которыми вы работаете, но кто знает, бывает, что сотрудник увольняется, может, его увольняют и так далее. И мы не хотим, чтобы у них была возможность каким-либо образом хранить учетные данные производственной БД на своих компьютерах.

Поэтому я подумал, что, возможно, вместо определения констант в файле сам файл может возвращать объект PDO, который, в свою очередь, не раскрывает учетные данные, которые он использует для подключения к базе данных:

<?php

// ...

var_dump($appContainer->get('db_connection'))

Выводит что-то вроде:

/path/to/htdocs/file.php:4:
object(PDO)[13]

Таким образом, я бы получил что-то вроде этого в коде начальной загрузки моего приложения:

<?php

// ...    

$containerConfig = [
   'db_connection' => function() {
      return require_once __DIR__ . '/../db_pdo_outside_document_root.php';
   }
];
$appContainer = new ApplicationContainer($containerConfig);

// Use the container and handle the request...

И внутри внешнего файла:

<?php
// db_pdo_outside_document_root.php
return new PDO('mysql:host=localhost;dbname=app_database', 
'db_user', 'db_fancy_passwd', [
    PDO::ATTR_PERSISTENT => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);;

Но я не знаю, достаточно ли этого или есть некоторые предостережения, о которых я должен знать (помимо того факта, что этот «обходной путь» немного уродлив).

Как вы думаете, смогут ли другие разработчики каким-либо образом прочитать учетные данные из возвращаемого значения $appContainer->get('db_connection') (предполагая, что он возвращает указанный выше объект PDO)?

Я также пробовал с ReflectionClass, и я не вижу никаких свойств этого объекта:

<?php

//...

$ref = new ReflectionClass($appContainer->get('db_connection'));
var_dump($ref->getProperties());

Выходы:

/path/to/htdocs/file.php:4:
array (size=0)
  empty

Что вы думаете об этом подходе? Не изобретение века, но похоже, что оно делает свое дело. Или, может быть, все еще есть способ получить доступ к учетным данным в коде приложения, о котором я не знаю.

Хотелось бы узнать ваше мнение.

Спасибо за внимание.

EDI: как указал @IsThisJavascript, код приложения, конечно, все еще может получить содержимое файла и, следовательно, получить доступ к учетным данным, поэтому все мои рассуждения были неправильными, поскольку он не рассматривал этот очень простой случай. Думаю, мне нужно найти другую стратегию, если она существует ...