Чи може приватний проксі приймати лише ваш застосунок?
Пояснює межі обмежень за назвою застосунку та User-Agent і відрізняє володіння обліковими даними від доказу конкретного виконуваного файлу.
Прямий проксі може вимагати облікові дані, обмежувати вихідні мережі та застосовувати політику призначення. Але ці засоби не доводять, що викликач — один конкретний виконуваний файл.
User-Agent або власний заголовок надає клієнт, і його можна скопіювати. Тому назва застосунку в запиті не годиться як єдині ворота до приватного проксі.
Використовуйте контроль доступу, який виражає те, що ви справді можете перевірити: авторизований обліковий запис, дозволене мережеве розташування та передбачені призначення. Захищайте й відкликайте клієнтські облікові дані через звичайний проєкт застосунку для роботи з секретами. Потім перевірте дозволені та відхилені запити щодо передбаченої межі доступу.
Навіть сильніша автентифікація клієнта встановлює лише володіння схваленим ключем або обліковими даними. Її не слід описувати як абсолютну гарантію того, що жодна інша програма не зможе використати ці дані.
Якщо вимога — це забезпечення цілісності керованих пристроїв або застосунків, позначте її як додаткову системну вимогу. Не обіцяйте цього правилом заголовка Squid, яке лише розпізнає рядок, обраний самим викликачем.