Любое решение сопряжено с рисками безопасности. Можно использовать проверенные годами инструменты и однажды быть взломанным (из собственного опыта). И вы можете заплатить много за решение безопасности и никогда не быть взломанным. Итак, вам нужно всегда сравнивать усилия с отдачей.
По сути, в вашем случае нужно защищать 4 "двери": 1. Авторизация (перехват пароля или, например, неправомерное использование cookies) 2. HTTP-протокол 3. Вход приложения 4. Другие способы доступа к вашей базе данных (не через http, например, по ssh порту со слабым паролем, взяв ваш компьютер или жесткий диск и т. д. В некоторых случаях вам нужно правильно зашифровать том)
1 и 4 не являются специфическими для Пролога, но только 4 имеет некоторую специфику в случае локальных серверов.
Защищать уровень протокола http означает не разрешать запросы, которые могут получить контроль над вашим сервером swi-prolog. Для этой цели я рекомендую установить обратный прокси-сервер, такой как nginx, который может предотвратить атаки на этом уровне, включая некоторые типы DoS. Таким образом, браузер свяжется с nginx, и nginx перенаправит запрос на ваш сервер, если это правильный HTTP-запрос. Вы можете использовать любой другой сервер вместо nginx, если он имеет аналогичные функции.
Вам нужно установить правильный ключ ssl и разрешить ssl (https) на обратном прокси-сервере. Его не должно быть в вашем swi-prolog сервере. Https зашифрует всю информацию и будет связываться с swi-prolog по http.
Подумайте об авторизации. Есть методы, которые очень легко сломать. Вам нужно изучить эту тему, там много информации. Я думаю, что это самая важная часть.
Проблема с вводом данных в приложение — самый известный пример — «внедрение sql». Примеры изучения. Все хорошие веб-фреймворки имеют «входные» процедуры для очистки от всех возможных инъекций. Возьмите существующий код и перепишите его на прологе. Кроме того, проверьте все поля ввода с очень длинной строкой, разными кодировками и т. д.
Вы можете видеть, что безопасность не так проста, но вы можете выбрать соответствующие меры с учетом последствий взлома.
Также подумайте о возможном злоумышленнике. Если кто-то очень заинтересован, в частности, в получении вашей информации, все упомянутые методы хороши. Но это может быть редкий случай. Чаще всего хакеры просто сканируют интернет и пытаются применить известные хаки ко всем найденным серверам. В этом случае вашим лучшим другом должны быть Honey-Pots и сам пролог, потому что вероятность хакерского интереса к внутренностям swi-prolog крайне мала. (Хакеру нужно хорошо изучить код сервера, чтобы найти дверь).
Поэтому я думаю, что вы найдете адекватные методы для защиты всех конфиденциальных данных. Но, пожалуйста, никогда не используйте пароли с комбинациями словарных слов и одного и того же пароля более чем для одной цели, это самое главное правило безопасности. По той же причине вы не должны предоставлять своим пользователям доступ ко всей информации, но защита должна быть на уровне приложения.
Случаи, характерные для локального сервера, - это хороший брандмауэр, правильная настройка сети и шифрование раздела жесткого диска, если ваш локальный сервер может быть украден «хакером».
Но если вы имеете в виду, что приложение должно быть доступно только из вашей локальной сети, а не из Интернета, вам нужно гораздо меньше усилий, в основном вам нужно проверить настройки маршрутизатора/брандмауэра и 4-ю дверь в моем списке.
В случае, если у вас очень ограниченное количество известных пользователей, вы можете просто предложить им использовать VPN, а не защищать свой сервер, как в случае «глобального» доступа.
person
Sergei Lodyagin
schedule
01.10.2013
