Перш ніж додати налаштування проксі до публічного репозиторію
Відокремте кінцеву точку проксі від облікових даних проксі та поясніть, чому публікація першої не забезпечує контроль доступу.
Ім'я хоста проксі у файлі конфігурації — не те саме, що пароль проксі. Публікація будь-чого з цього заслуговує на усвідомлене рішення, але наслідки різні.
Кінцева точка повідомляє читачам, де сервіс може бути доступним. URL на кшталт http://name:[email protected]:8080 також дає їм придатні облікові дані. Його ніколи не слід вважати безпечним лише тому, що він виглядає як адреса.
Прихована адреса — не політика доступу
Приватному проксі потрібні засоби контролю, доречні для його користувачів: автентифікація, дозволені мережі клієнтів і обмеження призначення. Тримання адреси поза репозиторієм їх не замінює. Публічно доступний сервіс може бути виявлений і без читання вашої конфігурації.
І навпаки, публікація адреси сервісу не доводить, що він відкритий. Кінцева точка може й далі вимагати облікові дані або бути доступною лише з передбачуваної мережі. Перегляньте реальну межу доступу, а не припускайте, що секретність і автентифікація означають одне й те саме.
Для прикладів, якими можна поділитися, використовуйте документаційні імена хостів і опускайте секрети. Тримайте приватні налаштування усталеним механізмом секретів або локальної конфігурації проєкту. Будьте уважні до згенерованих файлів і скопійованих діагностичних журналів, які можуть містити повний URL з обліковими даними.
Якщо облікові дані було розкрито, спершу усуньте їхню корисність, відкликавши або змінивши їх. Редагування останнього файлу не видаляє копії, попередні коміти чи кешований вміст. Настанови GitHub щодо чутливих даних пояснюють, чому очищення історії — окреме завдання.
Корисний огляд перевіряє обидві сторони: який доступ надає опублікована інформація і чи залишається проксі обмеженим навіть тоді, коли його адреса відома.