Node.js является сформировавшимся для корпоративной безопасности?
Да.
Сам Exchange Server не поддерживается на 32-разрядных версиях Windows, но Ваши DC/s не должны быть 64-разрядными. Данные, хранившие в Active Directory, не существенно отличаются между 32-и 64-разрядные выпуски Windows.
Хотя я не могу указать ни на какие определенные дефекты, о которых сообщают, я был бы озабочен node.js архитектурой - куда Ваш код работает как часть кода веб-сервера. В то время как с чем-то как mod_php, существует все еще только единственный процесс, обрабатывающий и HTTP и логические уровни, между этими 2 существует четкое функциональное разделение, и интерфейс между веб-сервером и логическим уровнем был явно разработан и протестирован для размещения отказов - особенно в логическом уровне.
Кроме того, существует много инструментов, доступных для веб-серверов (Apache в особенности), которые упрощают управление, и (используемый правильно) улучшают безопасность.
Другое основное соображение является доступностью навыков/поддержки/обучения - независимо от ее качества / утилита, node.js имеет большое наверстывание, чтобы сделать по сравнению с другими платформами веб-разработки.
Наша группа разработчиков рассматривала использование Node.js
То, что Вы конкретно пытаетесь поставить то, что должно быть очень защищенным приложением на платформе, с которой (судящий по Вашему оператору выше) Вы не полностью знакомы, кажется, очень опрометчиво. Большинство уязвимостей системы обеспечения безопасности в веб-приложениях возникает не из-за отказов в среде разработки, но в отказах в сделанном на заказ коде, прибавляемом вершина.
Конечно, использование обратного прокси упростило бы получение стандартного входа HTTP, anomoly обнаружение и уменьшило бы влияние нападений протокольного уровня.
Один из лучших инструментов для создания безопасных веб-приложений является mod_security - AFAIK, это только доступно для выполнения в Apache - но это предложило бы возможность (наряду с mod_proxy) развертывания системы фронтенда, обеспечивающей обычную функциональность веб-сервера (вход, статическое содержание) наряду с, скажем, услугами аутентификации и использованием node.js как бэкенд.
Идеально, целое приложение должно быть ограничено или интранет или VPN или по крайней мере IP-адресом клиента, особенно если это будет используемым каким-либо видом федерального чиновника. Если взломщик не может даже поразить веб-сервер, то они, конечно, не смогут использовать Node.js, правильно?
В основном это помогает с параллелизмом, если этот параллелизм связан с вводом-выводом, как вы, вероятно, знаете.
Вариант, который намного быстрее, чем NodeJS, - это использование mono + F # и его поддержки асинхронности. Затем вы можете использовать HttpListener, чтобы максимально приблизиться к сокету, как с NodeJS.
Не обращая внимания на варианты выше; SELinux и chroot, вероятно, являются хорошими инструментами для остальных.
По моему опыту, большинство уязвимостей в коде, которые приводят к выполнению произвольного кода, связаны либо с плохими разрешениями на запись в базу данных / диск, что позволяет запрашивать файлы, которые вы загрузили, либо или из неуправляемого кода, который плохо управляет памятью / проверяет границы.
Обратный прокси также является хорошим вариантом, потому что они надежны в боях. Например, HAProxy - он может обрабатывать как WebSockets, так и обычный HTTP в своих последних версиях.
Затем вы можете использовать некоторые инструменты для фактического тестирования реализации. Google использует инструмент skipfish: https://code.google.com/p/skipfish/
Вы можете использовать фаззер на уровне протокола, а также на уровне приложения, но это все менее и менее важно. более того, ваш компилятор доказывает за вас, например, с JS, где вы не можете изменить тип экземпляра объекта или F #, где у вас есть более статическая проверка, например, с размеченными объединениями и единицами измерения.
Наконец, если вы действительно хотите безопасность кода, я бы порекомендовал Stact Framework с Haskell, который вы можете сделать очень безопасным с помощью компилятора. С Haskell вы даже можете писать небольшие доказательства с помощью Coq, помощника по доказательству или Agda (см. Haskell Theorem Provers )
Для связи с вашими серверами вам, вероятно, понадобится DNS. Вы' Вам также необходимо защитить это с помощью DNSSec, иначе вы можете получить DNS Poisoning.
Если они получат доступ к LAN, вы можете получить ARP Poisioned, что означает, что кто-то может украсть ваши IP-адреса; но вы можете настроить DNS-сервер для статического обслуживания всех, кто находится в сети, в таблице поиска IP-to-MAC, которую также проверяют все хосты.
Наконец, вы можете добавить IDS, например Snort , чтобы вашей сети и запишите "нормальное" выполнение вашей программы, чтобы вы также могли реагировать на аномалии.