Можно ли разрешать неаутентифицированные вызовы RPC для серверов за корпоративным брандмауэром?

Question

Наше распространяемое приложение использует Microsoft RPC для межпроцессного взаимодействия.Начиная с Windows XP с пакетом обновления 2 (SP2) и Windows 2003 с пакетом обновления 1 (SP1), Microsoft затянула болты , поэтому теперь программы на двух разных компьютерах не могут общаться так легко.

Либо они оба должны работать под соответствующими учетными записямитак, чтобы аутентификация прошла успешно, или RPC-сервер должен «открыть дыру», вызвав RpcServerRegisterIf2 () с флагом RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, чтобы разрешить вызовы без аутентификации как до изменения «затягивания».

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

Если спросить здесь, потому что это проблема проектирования программы, а не установки.

Answer 1

Не безопасно вообще.Да, это действительно скомпрометирует компьютер.

Люди, которые считают, что атаки или злонамеренное поведение могут осуществляться только за пределами «корпоративного брандмауэра», в конечном итоге будут очень разочарованы: -)

Я бы никогда делегировать ответственность за обеспечение безопасности моих систем или приложений сторонним лицам.Это просто напрашивается на неприятности.

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

Я бы подумал, что в корпоративной среде все пользователи будут централизованно поддерживаться в любом случае (например, AD), чтобы проблема с аутентификацией была минимальной.