Защита строки подключения SQL Server в автоматическом настольном приложении

У нас есть приложения, работающие на серверах Windows 7 Pro в полевых условиях. Они могут оставаться без присмотра и, следовательно, небезопасными. Они подключаются к серверу Sql в Azure. Мы пытаемся найти способ защитить строку подключения, которая в настоящее время представлена ​​в виде обычного текста. Мы можем зашифровать строку, но это просто перемещает проблему к защите ключа. Это не веб-приложения. Наша главная забота состоит не в том, что машины будут украдены, а в том, что логин будет раскрыт. Мы можем использовать технологию запутывания, такую ​​как ConfuserEx, чтобы очень сложно было найти незашифрованную строку, но есть ли для этого лучшая практика? Я понимаю, что SAML, WSFED, OAUTH, OPENID — это поддерживаемые протоколы, используемые Azure AD для аутентификации запросов приложений, но я думаю, что для включения в не-веб-приложения это большой холм.


person Ron    schedule 07.04.2016    source источник


Ответы (1)


Я думаю, вы пытаетесь защитить не ту вещь.

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

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

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

Убедитесь, что у вас есть журналы аудита, которые вы можете просматривать и искать необычные действия (это то, что недавно начала делать Azure). Злоумышленник получит много ошибок отказа в доступе, поскольку он проверяет ограничения своей учетной записи. Научитесь их замечать.

Конечно, было бы гораздо лучше иметь API-интерфейс, в котором можно было бы иметь какой-то способ аутентификации и проверки, но я понимаю, что иногда нам приходится работать с тем, что у нас есть.

TL;DR

Не пытайтесь делать что-либо, кроме самого простого для шифрования/обфускации. Просто убедитесь, что когда кто-то получит вашу строку подключения, он не сможет причинить ей никакого вреда. Заблокируйте свою базу данных. Аудит. Посмотрите на Аудит, Часто.

person Michael B    schedule 07.04.2016
comment
Мы работаем удаленно над интерфейсом API. Но пока да, мы можем работать только с тем, что есть. Я предоставил базовое шифрование. Мы должны изучить наши роли пользователей БД. СПАСИБО!!!!!!!!!! - person Ron; 07.04.2016