Задать вопрос
  • Соединение 2 FreePBX?

    @nApoBo3
    Опишите схему подключения по портам и адресацию, пока включение в эту схему второго asterisk выглядит как дикий не нужный костыль
  • Должен ли разработчик заниматься ручным тестированием?

    @nApoBo3
    Tyranron, разница принципиальная, во всех случаях риски несёт собственник. Не говоря о том, что в РФ любые "штрафы" из оклада являются очень рискованными с точки зрения ТК, да и "премиальная" часть очень мало где корректно оформлена.
    А удержание премии не прописанное явно в положении о премировании и без оформления соответствующих бумаг очень приятно для трудовой инспекции.
  • Mikrotik перед сервером как лучше настроить и нужен ли?

    @nApoBo3
    Зачем. Проще раскидать по vlan и так и оставить несколько виртуальных интерфейсов на сервере.
  • Должен ли разработчик заниматься ручным тестированием?

    @nApoBo3
    Систематическое оказание услуг как "физ.лицо не законно, вы в какой то форме должны легализоваться. Есть существенное отличие между заказом продукта и разработкой продукта. Во многом оно определяется кто является собственником продукта и прибыли, а так же, соответственно несёт риски. Если мы говорим об отношении к собственноей разработке как к внешней, то есть акты приемки, есть ТЗ, есть ограниченные гарантии( обычно as is ). Но обычно в локальной разработке и строгого ТЗ нет, и приемки.
  • Как настроить распределённую сеть Active Directory и вытекающие?

    @nApoBo3
    Даня Джен,
    Во первых кто-нибудь кроме Microsoft'a использует azure ad?, а во вторых, чего бояться то?


    У меня статистики нет, но думаю да, с помощью azure ad можно сделать доменную авторизацию облачных сервисов, в гибридных инфраструктурах это актуально.

    И так планируем делать VPN, для программ нужен!


    Ну тогда на этом варианте и остановитесь. Только учите, что штатно тоннель поднимается после логина пользователя.

    Он и пришёл первый на ум, но как его реализовать?


    Насколько я понимаю он не рекомендуется Microsoft. Если очень нужно MS рекомендует развернуть AD LDS на периметре.

    По третьему варианту от MS есть решение DirectAccess. Машина как только цепляется к сети сразу сама строит туннель. Таким образом машина даже без активного сеанса и без действий пользователя сам подключается к локальным ресурсам.
  • Как настроить работу профилей пользователей AD по такому принципу?

    @nApoBo3
    Даня Джен,
    Если после выключения компьютер ничего никому не скидывает, то с другой машины эти данные доступны не будут.
    30 минут, 10 минут. Это не очень важно. Компьютер вылетел в процессе копирования и усе, приехали, коммутатор завис, провод плохо обжат и т.д.
  • Как настроить работу профилей пользователей AD по такому принципу?

    @nApoBo3
    1. Автономные папки в любом их вырианте. Например Folder Redirection. Это для папок с моими документами
    2. Настройки программ это перемещаемые профили. Но честно говоря больше геморроя чем профита, только если пользователь постоянно между машинами прыгает.
    3. Защита файлов очень абстрактный термин, что и от кого защищать и в какой степени, может у вас там вообще гостайна. Но предложенные методы ничем не хуже в этом плане по сравнению с vhd.
    4. Открывать доступ в вашем сценарии пользователь не сможет. Если вам нужна настройка доступа пользователем, то это уже общий ресурс. Можно даже на веб базе сделать. Например в том же onedrive. Но учтите, один раз дав пользователям такой инструмент, вы потом пожизненно обретаете свалку в сети.
  • Как подтвердить участие в проекте?

    @nApoBo3
    cup_of_sugar, руководитель первый должен быть в курсе.
    Если он не должен быть в курсе, то или контора не сильно адекватная, а значит про подтверждение участи можете забыть или вы.
  • Mikrotik и настройка QoS для Transmission, как реализовать?

    @nApoBo3
    Если трафик udp,
    ПО не использует собственных механизмов управления пропускной способностью,
    источники имеют скорость вышего вашего шэйпера.

    Да. В таком случае канал будет занят.

    И даже если ПО само управляет скорость отдачи на источнике трафика, учитывая как работает торрент, в случае с 100500 источников канал тоже будет занят, поскольку они не будут успевать согласовывать скорость. Но думаю в торрент протоколе такого функционал а нет.
  • Mikrotik и настройка QoS для Transmission, как реализовать?

    @nApoBo3
    theurs, да, но никак не влияет на канал. Трафик к вам все равно приходит и канал занят, просто вы его отбрасываете ( если речь о udp трафике ).
  • Как правильнее организовать перемещаемые профили для разных версий Windows?

    @nApoBo3
    xmurus, вполне вероятно, что ограничения на хранения данного кэша нет. Он храниться пока его не удалят.
  • Как правильнее организовать перемещаемые профили для разных версий Windows?

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

    BranchCache это вообще не про то и он доступен только на windows enterprise.

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

    @nApoBo3
    Ярослав Поляков,
    Идея не в том, чтобы "давайте не будем фиксить SQL Injection'ы


    Их не надо фиксить. Современные подходы не подразумевают их наличия, чтобы они были, их надо делать специально.

    Поэтому, могут быть разного рода уязвимости. Мы не можем исключать никакую. И в API, так же может быть уязвимость, согласен. Но в отличие от приложения с его кучей "декоративного" функционала и тоннами кода, отладить API более реально. Я бы скорее положился на "бездырочность" API с кодом из 500 строчек (и списком URLов из 10 строчек), чем на "бездырочность" всего приложения, с кодом на из 50 000 строк. Вероятность уязвимости ниже все таки.


    1. Составьте модель угроз. Любая безопасность начинается с этого.
    2. Увеличение кода и слоев ведет к увеличению кол-ва уязвимостей, а не к их уменьшению. Т.е. добавляя дополнительный слой, вы можете только добавить уязвимости, но не можете их сократить. Ничто не мешает ровно те же меры реализовать слоем выше.

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


    Нет, безопасность в это не состоит. Эшелонированная, почитайте определение, нужна для замедления продвижения противника. Безопасности она не добавляет. Файрволы не защищают от уязвимостей сетевых демонов, они сокращают площадь атаки.
    Если упрощенно смотреть на модель угроз, то мы пишем, злоумышленник может атаковать наш сервер по 22 порту. И тут вас спрашивают, а как же 123 порт, там же у вас может висеть сервис времени, а вы негде не прописали, что мы его отключаем, и проверяем что он отключен и предпринимаем меры чтобы его нельзя было включить. А вы в ответ, а нам все равно, мы от этой угрозы прикрылись фаерволом.

    Если обобщить. Все меры вы можете реализовать на уровне приложения и спускаться на уровень базы не обязательно. Права приложения на уровне базы минимизируются, не с целью защиты, а с целью минимизации потенциального ущерба, поскольку это самый простой способ его минимизировать( минимизация привилегий на любом уроне ). Реализация те же мер на уровне приложения будет дороже.
    Спускаясь на уровне базы с сложной логикой вы размазываете зоны ответственности и усложняете архитектуру, это усложняет тестирование и разработку и может добавить уязвимостей.
    Такой подход тоже можно реализовать. Но не следует смешивать одну зону ответственности в разных слоях. Т.е. если безопасность у нас реализуется на уровне базы, а это как правило будут хранимые процедуры, то вся безопасность будет именно там, и на уроне приложения ее нигде быть не должно.
    Но следует понимать какие издержки вы при этом понесете. Вам потребуется значительно более широкие компетенции, большее кол-во специалистов и появятся точки "синхронизации" которые будут сильно тормозить разработку и усложнять управление проектами. По этому так обычно не делают. Плюс реализовывать такие механизмы на уровне базы сложно, просто в следствии меньшего кол-ва специалистов с нужными навыками и менее продвинутого инструментария( да я знаю, что есть весь необходимый инструментарии, но им реально мало кто умеет пользоваться, хотя бы для того же тестирования хранимых процедур ).

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

    Они все сводятся к тому, что субъект либо имеет доступ к объекту (файлу, записи), либо не имеет, и это не меняется динамически.


    Это не совсем так, поскольку есть динамические роли, например владелец. В общем динамический подход реализуется в attribute based security.
    Если брать, то о чем вы пишите( 20 клиентов ), то такое обычно реализуют иначе. Через мониторинг и блокировку учетной записи по событию мониторинга.
    Поскольку в данном случае речь идет или о злонамеренных действиях пользователя, а значит с ним нужно разбираться и просто запретить действие не достаточно или о компрометации учетной записи, а значит ее в любом случае сначала блокируют( или используют как "ханейпорт" ).

    Начните с модели угроз.
  • Есть ли базы данных, хранилища, бэкенды для конфиденциальных данных?

    @nApoBo3
    Ярослав Поляков, вы не корректно подходите к безопасности. Составьте модель угроз и поймете, что ваша идея не походит для закрытия каких либо угроз из модели.

    Каким образом через приложение можно исполнить произвольный SQL код?
    1. Уязвимость в ПО на котором хостится ваш код.
    2. SQL инъекций. Если у вас эксплуатируется код подверженный SQL инъекциям, то ваших разработчиков нужно гнать поганой метлой, такое .... уже давно сложении написать, чем не написать.

    Если вы защищаете от первого, то надо понимать, что подобные уязвимости могут быть и в коде СУБД. А скомпрометированный сервер приложений позволит злоумышленнику собрать через ваше api все необходимы данные, включая и логины пароли всех пользователей.
    Если от второго, то нужно проводить аудит кода, поскольку в 2019 году писать код уязвимый к SQL инъекциям может только жутко дремучий джун которого к самостоятельно работе допускать нельзя и SQL инъекции будут только самой маленькой из ваших проблем.

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

    Сделать доступ к записи пользователя только после его аутентификации - возможно


    Пользователь при аутентификаций получает auth token, в котором есть id или пользователя или сессии, после чего запрос в базу идет через хранимую процедуру в которую это id передается.

    А лимитировать "дать не более 100 записей из табл. customers" за день


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

    Но как я уже сказал, это все не имеет особого смысла. Почитайте про модели безопасности их не так много и есть вполне конкретные практики как они реализуется. Вы изобретаете велосипед.
  • Какую версию Windows Server лучше купить для юр. организации?

    @nApoBo3
    VladVasilchenko, перечисленные вами проблема нет от 2003 server.
    Вообще используемая вами терминология говорит от том, что вы решили спихнуть все на то, что мол старая версия сервера, что вы от нее хотите. 2003 вполне успешно выполняет функции контроллера домена и файлового сервера, и никаких "багов" и отвалов дисков, не разваливающихся групповых политик и всего прочего не будет.
    60 устройств и 30 единиц офисной техники( вообще странно, что у вас всего по два компьютера на одну единицу сетевого офисного оборудования ) не создадут запредельную нагрузку на NAS( хотя конечно с WD не имел дело ) если нет никаких очень специфических сервисов.
    Вероятно у вас проблема где-то еще.
  • Пропадают ли метаданные фотографий, если скачать их из мессенджера?

    @nApoBo3
    АртемЪ, то что вы связываете обработку изображения и удаление метаданных, что не верно, второе не следует из первого. Из этого пользователь может сделать ложный вывод, если изображение обрабатывается ( преобразуется или перекодируется ), то метаданных в нем нет. Что так же не верно.
  • Пропадают ли метаданные фотографий, если скачать их из мессенджера?

    @nApoBo3
    АртемЪ, нет не естественно.
    Метаданные это данные о данных. Исходные данные из себя представляют изображение( не файл, а именно объекты на изображении, файл это лишь формат сохранения, а не сами данные ), у самого изображения ничего не поменялось, ни дата съемки, ни координаторы съемки, ни автор и т.д.
    По этому как раз "естественным" поведением в данном случае является сохранение метаданных.
    Именно исходя из этого, поведение в данном случае ничем не гарантированно и не следует опираться на "естественность" удаление метаданных. И если вам нужно обеспечить их сохранность или их удаление, то следует сделать это на своей стороне не рассчитывая на поведение сервиса.
  • Пропадают ли метаданные фотографий, если скачать их из мессенджера?

    @nApoBo3
    АртемЪ, вам указывают на формальную ошибку, нет никакой связи между тем, что сервисы "изменяют" изображение и потерей метаданных, никто не мешает сервисам менять изображение с сохранением метаданных или передавать исходное изображение с удалением таких данных.