Формулировка задания: Доступ к файлу X, находящемуся на сервере Y, осуществляется по протоколу Z. В таблице фрагменты адреса файла закодированы буквами от А до Ж. Запишите последовательность этих букв, кодирующую адрес указанного файла.

Задание входит в ЕГЭ по информатике для 11 класса под номером 12 (Организация компьютерных сетей. Адресация).

Рассмотрим, как решаются подобные задания на примере.

Доступ к файлу www.txt, находящемуся на сервере ftp.net, осуществляется по протоколу http. В таблице фрагменты адреса файла закодированы буквами от А до Ж. Запишите последовательность этих букв, кодирующую адрес указанного файла.

Адрес файла в сети интернет выглядит так:

Сначала указывается протокол http (Б), далее – двоеточие и 2 слеша (Г). После этого указывается название сервера ftp.net (Ж и Д). Так как нет указания на дополнительные папки, файл находится в корне сервера. Значит, далее идет слеш (В) и название файла www.txt (Е и А).

Таким образом, последовательность букв БГЖДВЕА кодирует адрес указанного файла.

Поделитесь статьей с одноклассниками «Доступ к файлу, находящемуся на сервере, осуществляется по протоколу – как решать».

Доступ к файлам и папкам через протокол FTP

Об основах работы протокола FTP я рассказывал в статье «Что такое FTP? FTP сервер и FTP клиент». Поэтому сейчас предлагаю перейти к практике и рассмотреть различные способы работы с FTP сервером.

Получить доступ к файлам и папкам FTP сервера из операционной системы Windows можно следующими способами:

  1. Через браузер
  2. Через проводник Windows
  3. И при помощи специальных программ, так называемых FTP клиентов

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

Теме работы с FTP через командную строку я посвящу отдельное видео, где мы рассмотрим основные команды, а также создадим скрипт, для выполнения автоматических задач обмена данными с FTP сервером.

А в данном видео рассмотрим работу через проводник, браузер и FTP клиент

Для начала, нам понадобятся данные для подключения к FTP серверу (адрес FTP сервера, логин и пароль для доступа к нему)

Для того, чтобы получить доступ к файлам и папкам FTP сервера через браузер, мы можем запустить браузер либо ввести нужный адрес в утилиту «Выполнить». Она автоматически откроет введенный адрес в браузере, который указан по умолчанию в данной системе.

Недостатки:
— можем только просматривать файлы

Для того, чтобы получить доступ к файлам и папкам FTP сервера через проводник Windows достаточно указать его путь в адресной строке проводника.

Здесь мы уже можем удалять фалы, копировать несколько файлов, создавать папки и копировать файлы и папки на FTP сервер.

Недостатки:
— не можем изменять файлы
— не можем копировать файлы внутри FTP сервера

Чтобы получить максимум возможностей работы с файлами и папками на FTP сервере, нам понадобится FTP клиент. И в рамках данного видео мы рассмотрим, пожалуй, самый популярный из бесплатных, это FTP клиент FileZilla.

Ссылка на скачивание FTP клиента FileZilla

Удобство работы в ней заключается в том, что вы можете добавить сразу несколько FTP аккаунтов и легко переключаться между ними. А также можно редактировать файлы на самом FTP сервере. Точнее не на самом FTP, но процесс передачи файлов скрыт от пользователя и может складываться впечатление, что он редактирует файл на сервере. Хотя, файл копируется на компьютер, на нем редактируется и отправляется обратно на сервер при сохранении изменений.

Допустим, сотрудник Петя увольняется со скандалом, и вам нужно сделать так, чтобы он ничего напоследок не поломал. Или Вася переводится в другой отдел, и ему не следует больше копаться в файлах своего бывшего подразделения.

Теперь самое интересное: нужно каким-то образом вспомнить, к каким конкретно данным у этих товарищей был доступ, и что следует прикрыть в первую очередь.

Если с доступом к приложениям все очевидно и просто, то о файловых ресурсах такого не скажешь.

Наш корпоративный файловый сервер представлял собой достаточно печальное зрелище. С одной стороны — накопленные за годы объемы данных, а с другой — наследие в виде нигде не учтенных прав доступа, предоставленных предыдущими поколениями администраторов. Все это происходило еще до внедрения системы заявок на доступ и оперативно уже никак не разобраться.

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

Вот что мы пробовали:

В итоге, на Powershell был написан скрипт для сбора данных через Get-Acl и последующего автоматического формирования отчета по форме, согласованной со службой безопасности. Но сразу всплыл ряд минусов:

Слишком неудобно каждый раз запускать скрипт и часами ждать, пока сформируется матрица доступов;

Не подошел вариант ведения учета в виде бумажных заявок. Главным образом, из-за отсутствия механизма автоматического поиска;

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

    • Лучшим решением проблемы стала организация структурированной системы доступов на основе ресурсных групп.

    Обычно администраторами применяются два метода предоставления доступа:

    Непосредственно учетной записи пользователя. Если не вести подробный протокол назначения прав, то быстро возникнет неразбериха;

  • Права на группу ролевого доступа. Тот же недостаток, что и в предыдущем случае. К тому же, без протокола назначения прав сложно понять, используется ли конкретная группа кем-нибудь, или может быть удалена.

    • В качестве альтернативного и более удобного варианта можно использовать модель ресурсных групп. Это обычные группы безопасности, которые отвечают следующим требованиям:

    Предоставляют права доступа только к одному сетевому ресурсу или подкаталогу, которые могут иметь несколько групп доступа с разными правами;

    Могут быть вложенными;

  • При необходимости предоставляют права только к каталогам. Желательно избегать назначения прав на отдельные файлы.

    • Нарушение этих требований разрушит всю концепцию структурированной системы доступов.

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

    За годы использования такой системы я ни разу не пожалел о потраченном на подготовку времени. Теперь можно в любой момент посмотреть членство пользователя в группах и сразу определить, куда у него есть доступ.

    Структурированная система доступов ориентирована на файловые серверы Windows, но без проблем может быть адаптирована и под другие ОС.

    Структурированная система доступов на основе ресурсных групп — это не вариация на тему ролевого доступа, а его важный элемент

    Доступ к общему сетевому ресурсу или подкаталогу предоставляется только соответствующим ресурсным группам — локальным "Administrators" и “System”. Каждый общий каталог должен рассматриваться как корень дерева, в котором все доступы наследуются подкаталогами от родительской папки. Права доступа на подкаталог могут быть предоставлены независимо от прав на родительский каталог. Я буду иллюстрировать основные идеи на примере собственного сервера и его структуры папок.

    Если нужно на каком-то подуровне отключить наследование или установить запрет доступа – значит, с точки зрения информационной безопасности, структура каталогов выбрана неверно. Информация ограниченного доступа не должна размещаться на ресурсе с более широким доступом из-за риска ее компрометации.

    Глубина вложений каталогов на файловом сервере может быть произвольной. Но если часто приходится выдавать права на подкаталоги ниже 3 – 5 уровня, то такая структура станет перегруженной и потребует оптимизации.

    Имя нового файлового сервера "FILESRV1". На файловом сервере в корне диска для данных создан каталог с именем “Shares”. Отключено наследование прав доступа от родительского каталога и ограничен доступ

    Открываемые в общий доступ каталоги будут создаваться только в папке "Shares". Имя такого каталога должно совпадать с соответствующим именем общего файлового ресурса – например, “Public”.

    Для упорядоченного размещения данных в Active Directory создана структура организационных единиц "…GroupsShares. ". Организационные единицы создаются для каждого файлового сервера и общего файлового ресурса. Для подкаталогов организационные единицы не создаются

    Для примера я создал следующие ресурсные группы:

    Последние две нужны для предоставления отдельным сотрудникам расширенных прав на каталог "2016".

    Теперь нужно включить все это в состав группы "FILESRV1-Public"

    В организационной единице с именем общего файлового ресурса создаются группы безопасности:

    "имя_сервера-имя_общего_файлового_ресурса" для просмотра дерева каталогов без доступа к данным;

    "имя_сервера-имя_общего_файлового_ресурса-R" для доступа к данным с правами чтения;

  • "имя_сервера-имя_общего_файлового_ресурса-W" для доступа к данным с правами на чтение и запись.

    • Эти группы обязательны для всех общих файловых ресурсов, в поле "описание" стоит указывать реальный сетевой путь.

    Если нужно предоставить права, начинающиеся с имени подкаталога, то в организационной единице общего файлового ресурса создаются две группы безопасности:

    Когда выдаете права, отличные от "только чтение" или “чтение и запись”, то вместо суффикса “R” или “W” используйте другую букву. Группы безопасности с особыми правами создаются только для тех каталогов, где это реально необходимо.

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

    Для предоставления доступа по сети лучше выдавать права к общим ресурсам группе "Authenticated Users", но можно использовать и “Domain Users” или “Everyone”. Разрешения на уровне файловой системы не позволяют получить несанкционированный доступ к данным без явного разрешения.

    На уровне файловой системы к каталогу "Public" предоставлены соответствующие права доступа для групп

    Аналогично установлены права доступа для каталога "2016"

    Никаких дополнительных действий с каталогом "Новости" выполнять не требуется

    Теперь члены групп "FILESRV1-Public-Новости-2016-R" и “FILESRV1-Public-Новости-2016-W” получат доступ только к папке “2016”, а пользователи из “FILESRV1-Public-R” и “FILESRV1-Public-W” – к общему сетевому ресурсу “FILESRV1Public” и всем его подкаталогам.

    Конечно, при создании ресурсов масса времени уходит на подготовку, но зато мы получаем следующие преимущества:

    Освобождаем себя от постоянных работ по предоставлению доступа с помощью делегирования этих функций ответственным сотрудникам;

  • Можем в любое время посмотреть, какими правами и на какие папки обладает пользователь.

    • Даже если сейчас ваш файловый сервер похож скорее на большую флешку, то через 2 — 3 года он вполне может превратиться в традиционную «файлопомойку» со всеми вытекающими проблемами.

    Если вы знаете более простые методики организации и контроля прав доступа – обязательно делитесь опытом в комментариях.

    Похожие публикации

    • 16 июня 2016 в 14:09

    Ошибки и проблемы серверов большой тройки: часть третья. IBM

    Ошибки и проблемы серверов большой тройки: часть вторая. HP

    Ошибки и проблемы серверов большой тройки: часть первая. Dell

    Комментарии 58

    >Допустим, сотрудник Петя увольняется со скандалом, и вам нужно сделать так, чтобы он ничего напоследок не поломал

    Почему-то не упомянут пункт 0: «Блокируем его учетку».

    Т.е. предварительно он не мог уже накосячить? И вы только по факту скандала начинаете перекрывать доступы?

    Наблюдал одно феерическое увольнение: Во всем офисе вырубается интернет, сотрудников вызывают к шефу на ковер, в этот момент блокируют их учетки и они перестают иметь доступ к данным. Им сообщают, что они уволены с сей минуты и должны покинуть свои рабочие места. Сотрудники возвращаются на свои места за вещами, видят что их компы залочены, начинается крик, их вежливо просят покинуть помещение. Те просят вернуть им «фотки», которые у них на компе и вообще ***** ****. Их сопроводят на выход.

    Потом в этом офисе убили всю инфраструктуру и поставили бесконтрольную шару на *nix, но это уже совсем другая история.

    > сотрудник подал заявление и у него есть еще две недели

    А вы случайно не забыли, что уведомление за две недели — это норма, защищающая работодателя, а не сотрудника? Пусть пишет заявление на увольнение с сегодняшнего дня, работодатель вправе сказать «хорошо, уходи». Зачем держать потенциально опасного и, вероятно, уже бесполезного человека, да ещё и платить ему.

    Что значит «с достаточно широкими правами»? Достаточно широкими правами для чего, для удаления каких-либо документов? Это почти любой сотрудник.
    И что значит «уволить без ущерба для бизнеса»? Любое увольнение — это потеря денег, некоторый ущерб, независимо от наличия прав у увольняемого. А если увольнение человека приводит к остановке бизнеса, то это либо топ, либо у компании большие проблемы с преемственностью и менеджментом.

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

    А я например менял рутовые пароли в то время, когда в соседнем помещении текущий ИТ отдел оповещали об увольнении с этой минуты.
    Еще могу вспомнить аналогичный инцидент, когда админа компании в соседнем офисе забирала группа захвата прямо на рабочем месте — промшпионаж.

    > Share Permissions не должны включать Full Control

    Это весьма спорная рекомендация — применять к одному объекту права из двух совершенно разных источников тоже не есть хорошо. Явно настаивать права владельца можно, например, так — https://technet.microsoft.com/en-us/library/dd125370%28v=ws.10%29.aspx

    Схема немного похожа на нашу.

    Корень DFS, в нём публикуются все общие ресурсы.
    Каждому ресурсу назначено три группы:
    1. Share Read (операторов архивов, ботов, автоматизированных задач обслуживания и т.п.), в основном только для чтения.
    2. D DFS ShareName (Read) — группа доступа только для чтения.
    3. D DFS ShareName (Write) — группа доступа с правами записи.

    Чтобы дать пользователю доступ в каталог — достаточно добавить его в группу.
    Чтобы запретить пользователю доступ — достаточно убрать его из группы.

    Группу на явный запрет доступа (типа D DFS ShareName Access Denied) создавать не требуется — все общие ресурсы в DFS опубликованы с настройкой отображения на основе прав доступа. Т.е. если пользователь не входит в соответствующую группу — он общий ресурс в корне DFS просто не увидит.
    Таким образом точка входа у всех пользователей одна (корень DFS), но видит каждый из них те ресурсы, на которые у него есть права доступа (чтение и/или запись).

    Если сотрудник увольняется «по-хорошему» — то ставится дата истечения учётной записи равной дате увольнения + 1 день. После чего в день увольнения учётная запись удаляется (в корзину), заодно и из групп.
    Если сотрудник увольняется «по-плохому» — то учётка блокируется сразу, и опять же удаляется из всех групп.

    А отключение наследования — головная боль. Проблему, когда есть каталог, к которому имеют доступ на чтение или запись Вася, Петя, Дима, а внутри него каталог, к которому (и только к нему) нужно дать доступ Косте — так пока и не смогли решить. Очень много действий с каталогами приходится делать.
    Поэтому, решили в принципе не отключать наследование (для группы администраторов DFS, ShareRead), а создавать такие хитрые ресурсы, посредством публикации в корне DFS с назначением прав отдельной группе пользователей.