learn-cyber · lesson 6 · multi-tenancy

One group per hotel

The first multi-tenancy skill: organize every hotel's machines into a clean unit, and configure that whole unit's monitoring from a single file you write once.

The problem multi-tenancy solves

You took on two clients: The Grand Plaza (a 200-room city hotel) and Seaside Inn (a small coastal property). Each has a handful of machines running agents — front-desk PCs, a PMS server, a couple of POS terminals. All of those agents report to your one Wazuh manager.

Two questions immediately appear. First, how do you say "monitor the POS binary directory on all the Grand Plaza machines" without logging into each one by hand? Second, how do you make sure the Grand Plaza's data and the Seaside Inn's data never get tangled together? This lesson answers the first. Lesson 7 answers the second.

What a group actually is

A group is just a label you attach to agents on the manager. Every agent belongs to at least one group (the built-in default group if you never say otherwise). When you put an agent into grand-plaza, you're declaring "this machine belongs to that hotel, and should be monitored the way that hotel is monitored."

An agent can belong to more than one group at once, and its configuration is the combination of them all. So the Grand Plaza's PMS server might be in both grand-plaza (everything that hotel gets) and a cross-cutting pms-servers group (extra PMS-specific monitoring you apply to every hotel's PMS). The hotel groups slice your fleet by client; the role groups slice it by machine type. You'll lean on the per-client groups first — they're the backbone.

Composition is powerful but easy to over-use early on. Start with one group per hotel. Add cross-cutting groups like pms-servers or pos-terminals only once you have a configuration you genuinely want to share across clients.

Managing groups: three ways, same result

You can create and assign groups three ways, and they all do the same thing on the manager.¹

• The dashboard — point and click, good for a quick look or a one-off move.
• The agent_groups CLI tool — on the manager, scriptable, the workhorse when you're onboarding.
• The Wazuh API — for automation, when you wire group creation into your onboarding runbook.

Here's the CLI shape. Create a group for each hotel, then confirm:

# on the Wazuh manager
/var/ossec/bin/agent_groups -a -g grand-plaza
/var/ossec/bin/agent_groups -a -g seaside-inn

# list groups to confirm they exist
/var/ossec/bin/agent_groups -l

You assign an agent to a group at enrollment — the deploy wizard's "group" field you met in Lesson 4 lets you pick the hotel as you roll the agent out — or afterwards from the manager:

# put agent 003 into the grand-plaza group
/var/ossec/bin/agent_groups -a -i 003 -g grand-plaza

Treat these commands as illustrative of the shape, not gospel flags — check agent_groups -h on your version. The point to carry away is the workflow: create the hotel's group, then put that hotel's agents in it.

Centralized configuration: write it once

Now the payoff. Every group has a shared configuration file on the manager at a fixed path:

/var/ossec/etc/shared/<group>/agent.conf

So the Grand Plaza's shared config lives at /var/ossec/etc/shared/grand-plaza/agent.conf. Whatever you write in that file is pushed automatically to every agent in the group. You define "what we monitor at the Grand Plaza" exactly once — which log files to read, which directories to run File Integrity Monitoring on, which POS paths to watch — and the manager distributes it to all their machines, including new ones you add later.²

A short agent.conf for the Grand Plaza might read the auth log and keep an eye on the POS binary directory:

<!-- /var/ossec/etc/shared/grand-plaza/agent.conf -->
<agent_config>

  <!-- read the Linux authentication log on every Grand Plaza host -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <!-- watch the POS binary directory for tampering (skimmer malware) -->
  <syscheck>
    <directories check_all="yes" realtime="yes">/opt/pos/bin</directories>
  </syscheck>

</agent_config>

Drop that file in, and every Grand Plaza agent — the one you deployed last month and the one you deploy tomorrow — starts reading /var/log/auth.log and watching /opt/pos/bin for changes. No SSH-ing into individual machines. Seaside Inn gets its own agent.conf under /var/ossec/etc/shared/seaside-inn/agent.conf with whatever its environment needs.

Why this is the backbone of the MSSP

Picture onboarding a brand-new hotel. The whole monitoring side of the job collapses to three moves:

1. Create the group — agent_groups -a -g new-hotel.
2. Drop in their agent.conf — the monitoring recipe for that property.
3. Deploy agents into the group — each one inherits the right monitoring the moment it enrolls.

That's how the service scales from one hotel to fifty without per-machine fiddling. Your monitoring policy lives in a handful of agent.conf files, version-controlled and reusable, instead of scattered across hundreds of endpoints.³

Check yourself

Retrieval practice — answering from memory is what makes this stick. Don't peek back up; take the guess.