Облачные вычисления (Cloud Computing): примеры сервисов, модели и как начать работать

Облачные вычисления (cloud computing) — это модель, в которой вычислительные ресурсы (серверы, диски, сети, базы данных, готовые приложения) берутся у провайдера по запросу через сеть и оплачиваются по факту использования. Вы не покупаете железо, а арендуете ровно столько мощности, сколько нужно сейчас.

Примеры облачных вычислений, которые встречаются каждый день:

• виртуальный сервер в Yandex Compute Cloud, Amazon EC2 или облачный сервер Selectel — это IaaS;
• управляемая база PostgreSQL в Yandex Cloud, VK Cloud или Cloud.ru, где обновления и бэкапы делает провайдер — это PaaS;
• почта и документы в Яндекс 360, Microsoft 365 или Google Workspace — это SaaS;
• функция, которая запускается на каждый HTTP-запрос в Yandex Cloud Functions или AWS Lambda, — это FaaS;
• объектное хранилище (Amazon S3, Yandex Object Storage) для картинок сайта, бэкапов и логов.

Ниже — строгое определение, таблица моделей с примерами, типы облаков и пошаговый старт с безопасной настройкой.

Что такое облачные вычисления по NIST

Самое цитируемое определение дает американский институт стандартов NIST в документе SP 800-145 (2011). Сервис считается облачным, если у него есть пять свойств:

1. Самообслуживание по запросу — ресурс создается в консоли или через API без звонка менеджеру.
2. Широкий сетевой доступ — работа через интернет или сеть со стандартных устройств.
3. Пул ресурсов — оборудование провайдера делится между многими клиентами.
4. Быстрая эластичность — мощность добавляется и убирается за минуты.
5. Измеряемый сервис — потребление считается (часы ВМ, гигабайты, запросы) и по нему выставляется счет.

Отсюда простой тест: арендованный на год физический сервер с ручной выдачей — это хостинг, но еще не облако в смысле NIST. Облачный сервер, который создается по API за минуту и тарифицируется поминутно или почасово, — облако.

Облако держится на виртуализации: одна физическая машина делится на изолированные виртуальные. Как это устроено, разобрано в статье о типах и принципах виртуализации.

Модели обслуживания: IaaS, PaaS, SaaS и FaaS

Модели различаются тем, где заканчивается зона ответственности провайдера и начинается ваша.

Важная граница: даже в SaaS данные и права пользователей остаются вашей ответственностью. Провайдер защищает свою инфраструктуру, но если вы раздали ссылку на документ «всем в интернете», это не его зона. Эту идею называют моделью разделенной ответственности (shared responsibility).

FaaS часто относят к разновидности PaaS (в определении NIST его нет), но выделяют отдельно: платите за время выполнения функции, а не за постоянно включенный сервер. Граница: у функций есть лимит времени выполнения и «холодный старт» — первый вызов после простоя медленнее.

Как выбрать модель под задачу:

• нужен полный контроль над ОС или нестандартное ПО — IaaS;
• нужно просто запустить веб-приложение и базу без администрирования — PaaS;
• нужна почта, документы, CRM для команды — SaaS;
• редкие события (обработка загруженного файла, вебхук, задача по расписанию) — FaaS.

Публичное, частное и гибридное облако

По NIST модели развертывания описывают, кому принадлежит и для кого работает инфраструктура.

Частное облако — это не «свой сервер в стойке», а тот же облачный слой (самообслуживание, API, пул ресурсов), развернутый для одной компании, например на OpenStack.

Для российских проектов на выбор влияет закон 152-ФЗ: персональные данные граждан РФ при сборе должны записываться и храниться в базах на территории России. Поэтому такие системы часто размещают у российских провайдеров или в регионах, расположенных в РФ.

Как начать работать с облаком: пошаговый план

Цель плана — артефакт: работающая ВМ с доступом по SSH, приватный бакет и настроенное оповещение о расходах. На первое знакомство обычно хватает вечера.

1. Аккаунт и платежный профиль. Зарегистрируйтесь у выбранного провайдера и привяжите оплату. У многих есть стартовый грант или бесплатный уровень — условия меняются, их нужно читать на странице провайдера в момент регистрации.
2. Бюджет и алерты — до создания ресурсов. В биллинге создайте бюджет (в Yandex Cloud — раздел «Бюджеты», в AWS — AWS Budgets) с уведомлением на 50% и 90% суммы. Сам по себе алерт только сообщает о расходе и ресурсы не останавливает; автоматическую реакцию (остановить ВМ, запустить функцию) нужно настраивать отдельно.
3. IAM: отдельные учетки и минимум прав. Не работайте ежедневно под владельцем аккаунта: включите ему MFA и уберите в сторону. Для себя заведите пользователя с нужной ролью, для скриптов и CI — отдельный сервисный аккаунт с правами только на свой каталог или проект.
4. Первая ВМ. Сгенерируйте SSH-ключ и передайте провайдеру только публичную часть.
5. Первый бакет. Создайте бакет в объектном хранилище с закрытым доступом и загрузите тестовый файл.
6. Уборка. Удалите тестовые ресурсы или хотя бы остановите ВМ.

Команда для ключа (работает в Linux, macOS и Windows 10/11 с OpenSSH):

ssh-keygen -t ed25519 -C "cloud-first-vm" -f ~/.ssh/cloud_first_vm
cat ~/.ssh/cloud_first_vm.pub

Будут созданы два файла: приватный cloud_first_vm остается у вас, содержимое .pub вставляется в поле «SSH-ключ» при создании ВМ. В группе безопасности (security group) откройте порт 22 только для своего IP-адреса, а не для 0.0.0.0/0.

Проверка результата: ssh -i ~/.ssh/cloud_first_vm <пользователь>@<публичный-IP> открывает консоль ВМ. Имя пользователя зависит от образа и провайдера, его показывают в карточке ВМ.

Если не получилось

• Permission denied (publickey) — указан не тот ключ или не тот пользователь. Проверьте флаг -i и логин из карточки ВМ.
• Connection timed out — порт 22 закрыт группой безопасности, у ВМ нет публичного адреса или ваш IP сменился.
• Счет не обнулился после остановки ВМ — это ожидаемо у многих провайдеров: остановленная ВМ не тратит процессор, но диски и зарезервированный публичный IP продолжают тарифицироваться. Полностью расход прекращает только удаление.

Безопасность: секреты и публичные бакеты

Две самые частые причины инцидентов у новичков — ключ доступа, закоммиченный в репозиторий, и бакет, открытый на чтение всему интернету. Ниже минимальный скрипт, который ловит обе проблемы: проверяет политику бакета в формате S3 и ищет ключи в файлах проекта. Проверено на Python 3.14.7.

import re
import tempfile
from pathlib import Path

# 1. Политика бакета в формате S3 (AWS). Первое правило открывает чтение всем.
POLICY = {
    "Version": "2012-10-17",
    "Statement": [
        {"Effect": "Allow", "Principal": "*",
         "Action": "s3:GetObject", "Resource": "arn:aws:s3:::demo-site/*"},
        {"Effect": "Allow",
         "Principal": {"AWS": "arn:aws:iam::123456789012:user/ci"},
         "Action": "s3:PutObject", "Resource": "arn:aws:s3:::demo-site/uploads/*"},
    ],
}


def is_public(principal):
    if principal == "*":
        return True
    if isinstance(principal, dict):
        values = principal.get("AWS", [])
        values = values if isinstance(values, list) else [values]
        return "*" in values
    return False


def public_statements(policy):
    stmts = policy.get("Statement", [])
    stmts = stmts if isinstance(stmts, list) else [stmts]
    return [s for s in stmts
            if s.get("Effect") == "Allow" and is_public(s.get("Principal"))]


# 2. Поиск ключей, забытых в коде проекта.
PATTERNS = {
    "aws_access_key_id": re.compile(r"AKIA[0-9A-Z]{16}"),
    "hardcoded_secret": re.compile(
        r"(?i)(secret|password|token|api_key)\s*=\s*['\"][^'\"]{8,}['\"]"),
}


def scan(root):
    hits = []
    for path in sorted(Path(root).rglob("*")):
        if not path.is_file() or path.name == ".env.example":
            continue
        for n, line in enumerate(path.read_text(errors="ignore").splitlines(), 1):
            for name, rx in PATTERNS.items():
                if rx.search(line):
                    hits.append(f"{path.name}:{n}: {name}")
    return hits


for s in public_statements(POLICY):
    mark = "PUBLIC?" if "Condition" in s else "PUBLIC:"  # условие проверить вручную
    print(mark, s["Action"], "->", s["Resource"])

with tempfile.TemporaryDirectory() as tmp:
    Path(tmp, "app.py").write_text(
        'import os\n'
        'KEY_ID = "AKIAIOSFODNN7EXAMPLE"\n'
        'db_password = "SuperSecret123"\n'
        'token = os.environ["APP_TOKEN"]\n')
    Path(tmp, ".env.example").write_text('APP_TOKEN="changeme-changeme"\n')
    for hit in scan(tmp) or ["секретов не найдено"]:
        print("SECRET:", hit)

Вывод:

PUBLIC: s3:GetObject -> arn:aws:s3:::demo-site/*
SECRET: app.py:2: aws_access_key_id
SECRET: app.py:3: hardcoded_secret

Что здесь происходит. Первое правило политики разрешает s3:GetObject любому ("Principal": "*") без условий — любой, кто знает имя файла, скачает его. Второе правило выдает запись конкретному пользователю CI, поэтому в отчет не попало. В файле app.py найдены ключ в формате AWS (AKIAIOSFODNN7EXAMPLE — учебный ключ из документации AWS) и пароль в коде; строка 4 читает токен из переменной окружения — так и надо.

Граница примера: это учебный фильтр, а не полноценный сканер. Правило с условием (Condition) он помечает как PUBLIC?, но не разбирает: условие может как закрыть доступ (например, только свой IP), так и оставить его открытым, поэтому такое правило нужно прочитать глазами. Не проверяются и списки доступа ACL, NotPrincipal и формат политик других провайдеров (у Yandex Object Storage свой формат принципалов). Для реальных проектов используют встроенные проверки провайдера и сканеры секретов в CI, например gitleaks.

Правила, которые закрывают большинство ошибок:

• секреты — в переменных окружения или в сервисе секретов провайдера (Yandex Lockbox, AWS Secrets Manager), а не в коде; .env — в .gitignore;
• утекший ключ отзывать сразу, а не только удалять из репозитория: он остается в истории Git и в чужих копиях;
• бакет по умолчанию закрыт; публичный доступ — только для действительно публичного контента (статика сайта) и отдельным бакетом;
• у сервисных аккаунтов — только нужные роли, у людей — MFA;
• включить журнал аудита действий в облаке (Yandex Audit Trails, AWS CloudTrail).

Шифрование бакета защищает данные на дисках провайдера, но не заменяет закрытую политику: если объекты шифруются ключом, которым управляет само хранилище (в AWS это SSE-S3, включено по умолчанию), при публичном доступе файл отдадут расшифрованным любому запросившему. Шифрование ключом из KMS анонимное чтение обычно блокирует, но полагаться на это вместо настроек доступа не стоит.

Выводы

• Облачные вычисления по NIST — это самообслуживание, сетевой доступ, пул ресурсов, эластичность и оплата по факту; без этих свойств это обычный хостинг.
• IaaS, PaaS, SaaS и FaaS различаются границей ответственности: чем выше модель, тем меньше администрирования, но данные и права всегда на вас.
• Публичное облако подходит для старта, частное и гибридное — при требованиях регулятора и чувствительных данных; в РФ на выбор влияет 152-ФЗ.
• Правильный порядок старта: бюджет и алерты, отдельные учетки с минимумом прав, затем ВМ с SSH-ключом и приватный бакет.
• Главные риски новичка — секреты в коде и публичные бакеты; утекший ключ нужно отзывать, а не просто удалять из репозитория.

Где применяется / связь с практикой

FAQ

Чем облако отличается от обычного VPS-хостинга?
Граница размыта: многие хостеры дают VPS по API с почасовой оплатой, и это уже близко к IaaS. Отличие облака — в экосистеме вокруг ВМ: IAM, управляемые базы, хранилища, балансировщики и автоматическое масштабирование.

Облако всегда дешевле своего сервера?
Нет. Для переменной нагрузки и старта облако обычно выгоднее, а для стабильной круглосуточной нагрузки на годы свое железо или аренда выделенного сервера могут обойтись дешевле. Сравнивать нужно полную стоимость, включая администрирование.

Что такое multi-cloud?
Использование нескольких публичных провайдеров одновременно, например чтобы снизить зависимость от одного из них. Цена — сложнее сеть, доступы и единый учет расходов.