Блокировать веб-приложение работает только для интрасети

через неделю в будущем у меня будет задание создать веб-приложение php, которое будет работать как процесс выставления счетов. Как только клиент и моя команда согласятся, веб-приложение будет развертываться только на своем внутреннем сервере. Для этого возникли некоторые фундаментальные вопросы.

  1. как мы заблокируем веб-приложение действительно действительно будет работать только на внутреннем сервере, а не в Интернете, как он спросил? причиной этой необходимости, затраты на работу были сокращены до некоторой степени. поэтому лучше всего, если он будет работать только в том случае, если клиент описал это: он будет развернут в интрасети только интрасети
  2. Что такое pro и cons развертывать только приложение php (со всем его сервером apache) в интрасети?
  3. В чем принципиальная разница между развертыванием приложения php в среде интрасети и в Интернете? есть ли что-нибудь, что можно рассмотреть?
  4. Я знаю, что мы можем поместить окна на флеш-диск или ручку-диск. У меня есть сервер autorun apache / php, который работает одинаково?

Настройте свою конфигурацию apache, чтобы только внутренняя сеть имела доступ к биллинговой системе с помощью mod_authz_host.

 <Directory /billing-system/docroot> Order Deny,Allow Deny from all Allow from *internal ip range* </Directory> 

Дополнительную информацию см. В http://httpd.apache.org/docs/2.1/mod/mod_authz_host.html#allow .

Просто разверните сервер WAMP (или LAMP) с вашим приложением на сервере внутри брандмауэра компании в своей сети.

Затем пользователи получают доступ к вашему приложению через имя сервера. например, если имя машины «Elmo», пользователи просто получают доступ к вашему приложению:

 http://elmo/index.php 

(это предполагает, что одно приложение работает на сервере на порту 80 по умолчанию)

Хитрость здесь заключается в том, что если эта машина не подключена к Интернету, и вам необходимо обновить ее снаружи, вам потребуется другой доступ, например SFTP

  1. Если интрасеть не подключена к Интернету, вы можете проверить это, проверив известный сайт, например, ваш домен или google.com, и отказываетесь работать, если он отвечает. Но такие интрасети становятся редкими. Возможно, было бы проще ограничить максимальное количество пользователей (общее или параллельное) – трудно проверить, что приложение недоступно извне.

  2. Меньше попыток взломать приложение (за брандмауэром компании) – это про и con, потому что тогда у вас может возникнуть соблазн уделять меньше внимания соображениям безопасности, потому что «ну, это внутреннее приложение!»

  3. Нет принципиальной разницы. В крупных организациях обычно используется некоторая форма единого входа, и вам придется интегрировать это; также конфигурация сервера и программное обеспечение могут быть ограничены ИТ.

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