Стратегии IIS для доступа к защищенным сетевым ресурсам

Проблема. Пользователь подключается к службе на компьютере, например к веб-сайту IIS или базе данных SQL Server. Сайт или база данных должны получить доступ к сетевым ресурсам, таким как общие папки (чаще всего) или базе данных на другом сервере. В доступе отказано.

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

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

Вот некоторые обходные пути, о которых я знаю:

  • Запустите IIS как пользователь пользовательского домена, которому предоставлены высокие разрешения

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

    Это также относится ко всем сайтам, работающим на IIS, а не только к выбранному сайту или виртуальному каталогу, которому требуется доступ, что является еще одной проблемой на поверхности.

  • Сделайте то же самое, но используйте пул приложений или индивидуально установленные учетные данные

    Не нужно запускать весь экземпляр IIS от имени конкретного пользователя: каждый сайт, приложение и папка могут быть настроены для работы в определенном пуле приложений или в наборе учетных данных, выбранном вручную. Это решает некоторую небольшую часть проблемы площади поверхности, но на самом деле не решает другие проблемы, связанные с управлением гранулярностью разрешений и выполнением этого для многих ресурсов.

  • Все еще используйте учетную запись IUSR, но предоставьте ей сетевые разрешения и настройте то же имя пользователя на удаленном ресурсе (не пользователь домена, а локальный пользователь)

    Это также имеет свои проблемы. Например, я использую общий файловый ресурс, на который у меня есть полные права для общего доступа, но я не могу войти на компьютер. Поэтому я должен найти подходящего администратора и попросить его сделать это для меня. Каждый раз, когда что-то должно измениться, это очередной запрос администратора.

  • Разрешить пользователям IIS подключаться как анонимные, но настроить учетную запись, используемую для анонимного доступа, на учетную запись с высоким уровнем привилегий

    Это даже хуже, чем предоставление полных привилегий IISR IIS, потому что это означает, что мой веб-сайт не может вообще использовать какой-либо вид безопасности.

  • Подключитесь с помощью Kerberos, затем делегируйте

    Это звучит хорошо в принципе, но есть все виды проблем. Прежде всего, если вы используете виртуальные веб-сайты, где имя домена, с которым вы подключаетесь к сайту, не является именем базового компьютера (как мы часто это делаем), то вам необходимо настроить имя участника службы на веб-сервере с помощью Microsoft. Утилита SetSPN. Это сложно и явно подвержено ошибкам. Кроме того, вы должны попросить администратора сети / домена изменить политику безопасности как для веб-сервера, так и для учетной записи домена, чтобы они были "доверенными для делегирования". Если вы не все понимаете совершенно правильно, внезапно вместо аутентификации Kerberos подразумевается NTLM, и вы можете только выдавать себя за роль, а не делегировать, и, таким образом, не обращаетесь к сети как пользователь. Кроме того, этот метод может быть проблематичным, поскольку иногда требуется, чтобы веб-сайт или база данных имели разрешения, которых нет у подключающегося пользователя.

  • Создать сервис или приложение COM+, которое выбирает ресурс для веб-сайта

    Сервисы и пакеты COM+ запускаются со своим набором учетных данных. Работать с правами пользователя с высокими привилегиями - это нормально, поскольку он может обеспечивать собственную безопасность и отклонять запросы, которые не являются законными, передавая контроль в руки разработчика приложения, а не администратора сети. Проблемы: я использую пакет COM+, который делает именно это на Windows Server 2000, для доставки высокочувствительных изображений в защищенное веб-приложение. Я попытался переместить веб-сайт на Windows Server 2003, и мне неожиданно было отказано в разрешении на создание экземпляра объекта COM+, весьма вероятно, разрешения реестра. Я немного повозился и не решил проблему, отчасти потому, что неохотно предоставлял учетной записи IUSR полные разрешения в реестре. Это похоже на ту же плохую практику, что и запуск IIS в качестве пользователя с высокими привилегиями.

    Примечание: это на самом деле очень просто. На выбранном вами языке программирования вы создаете класс с функцией, которая возвращает экземпляр нужного вам объекта (например, ADODB.Connection), и создаете dll, который вы регистрируете как объект COM+. В своем коде на стороне веб-сервера вы создаете экземпляр класса и используете функцию, и, поскольку она работает в другом контексте безопасности, вызовы сетевых ресурсов работают.

  • Сопоставить буквы дисков с акциями

    Это может теоретически сработать, но, на мой взгляд, это не очень хорошая долгосрочная стратегия. Несмотря на то, что сопоставления могут быть созданы с определенными учетными данными, и это могут делать другие пользователи, кроме администратора сети, это также будет означать, что либо существует слишком много общих дисков (небольшая детализация), либо слишком большое разрешение предоставляется всему файлу серверы (большая зернистость). Кроме того, я не выяснил, как сопоставить диск, чтобы IUSR получил диски. Сопоставление диска для текущего пользователя, я не знаю пароль учетной записи IUSR, чтобы войти в нее и создать сопоставления.

  • Переместите ресурсы локально на веб-сервер / базу данных

    Иногда я делаю это, особенно с базами данных Access. Должна ли база данных жить в общей папке? Иногда было проще всего перенести базу данных на веб-сервер или на сервер базы данных SQL (чтобы работал связанный сервер). Но я не думаю, что это отличное универсальное решение. И это не будет работать, когда ресурс - это сервис, а не файл.

  • Переместите сервис на конечный веб-сервер / базу данных

    Я полагаю, я мог бы запустить веб-сервер в своей базе данных SQL Server, чтобы веб-сайт мог подключиться к нему с помощью олицетворения и сделать меня счастливым. Но действительно ли нам нужны случайные дополнительные веб-серверы на наших серверах баз данных, чтобы это было возможно? Нет.

  • Виртуальные каталоги в IIS

    Я знаю, что виртуальные каталоги могут помочь заставить удаленные ресурсы выглядеть как локальные, и это поддерживает использование пользовательских учетных данных для каждого виртуального каталога. Я пока не смог придумать, как это решило бы проблему для системных вызовов. Пользователи могут напрямую обращаться к общим файлам, но это не поможет, скажем, классическим ресурсам доступа к коду ASP. Я мог бы использовать URL вместо пути к файлу для чтения удаленных файлов данных на веб-странице, но это не поможет мне установить соединение с базой данных Access, базой данных SQL-сервера или любым другим ресурсом, использующим соединение библиотека, а не просто читать все байты и работать с ними.

Хотелось бы, чтобы был какой-то "сервисный туннель", который я мог бы создать. Подумайте, как VPN делает удаленные ресурсы локальными. С более богатым механизмом псевдонимов, возможно на основе кода, почему даже соединения с базой данных не могут происходить в определенном контексте безопасности? Почему бы не специальный компонент Windows, который позволяет указать для каждого пользователя, какие ресурсы доступны и какие альтернативные учетные данные используются для подключения? Файловые ресурсы, базы данных, веб-сайты, вы называете это. Я предполагаю, что почти говорю о специализированном локальном прокси-сервере.

В любом случае, вот мой список. Я могу обновить его, если подумаю больше. У кого-нибудь есть идеи для меня?

Моя текущая проблема сегодня заключается в том, что мне снова нужен веб-сайт для подключения к базе данных Access в общей папке. Это снова мы...

5 ответов

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

Предположительно, как только акции настроены для каждого приложения (часть хорошо определенного процесса установки?), Они не сильно изменятся?

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

Если вы предпочитаете не использовать Kerberos, вы можете выдавать себя за пользователя при доступе к ресурсу, используя его токен, созданный, когда они были аутентифицированы с помощью аутентификации на основе форм. Это должно использовать сертификат SSL, по крайней мере, во время входа в систему.

Сделайте все эти сетевые / удаленные ресурсы локальными с помощью репликации SQL / доставки журналов и / или синхронизации файлов (вариант Microsoft Sync Framework - это вариант, хотя простота использования cygwin + rsync более привлекательна, IMO).

Конечно, все это зависит от того, как часто данные изменяются и / или вам нужна двусторонняя синхронизация или просто зеркалирование.

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

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

Оттуда я, вероятно, буду использовать учетные записи служб и имена компьютеров, поскольку они имеют смысл. Например, вы можете просто добавить учетную запись службы сервера базы данных (DOMAIN/MACHINENAME$) в группу, но если у вас есть кластер серверов веб-приложений, вы бы использовали общую учетную запись службы.

Другие вопросы по тегам