> ## Documentation Index
> Fetch the complete documentation index at: https://docs.osto.one/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure Server Access Policy

> Define who can reach which Secure Server, on which ports, and what happens to unmatched traffic.

The Server Access policy decides who can reach which Secure Server (or child server behind a Secure Gateway), on which ports, and what happens to traffic that doesn't match any rule. Default behavior is **deny all** — an implicit *Drop the traffic* rule sits at the lowest priority and only matching allow-rules let traffic through.

> **Path:** Policies → Server Access

## The page

The Server Access policy page is a single ordered table of rules, grouped by priority bucket.

| Column                     | What it shows                                                                                                |
| -------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Priority**               | Rule precedence. Rules group by bucket: *High*, *Medium*, *Low*. Within a bucket, the rule added first wins. |
| **Name**                   | Friendly name for the rule.                                                                                  |
| **Source**                 | Who the rule applies to — a Usergroup, an individual user, or *Any*.                                         |
| **Destination → Objects**  | Which servers — a specific Secure Server, a group, or *Any Server*.                                          |
| **Destination → Services** | Which ports/services — SSH, RDP, or a custom Service object defined under Objects.                           |
| **Action**                 | **Accept the traffic** or **Drop the traffic**.                                                              |
| **Actions**                | Edit and delete affordances per rule row.                                                                    |

A built-in **Implicit Policy** row sits at the bottom in the *Low* bucket with everything set to *Any* and Action *Drop the traffic*. It catches everything not explicitly allowed and **cannot be deleted** — it can only be out-prioritized by other rules.

<Note>
  First added policy has more precedence in the same priority bucket. Order within a priority bucket matters.
</Note>

## Adding a rule

<Steps>
  <Step title="Navigate to Server Access">
    Go to **Policies → Server Access** and click **Add Secure Server Access Policy +**.
  </Step>

  <Step title="Fill in the rule details">
    * **Name** — descriptive (e.g. *DevOps SSH to prod*).
    * **Priority** — dropdown. Default **High**. Other values: *Medium*, *Low*.
    * **Source** — dropdown of Usergroups and users from [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups). Tick **Any** to apply to all sources.
    * **Destination** — dropdown of registered Secure Servers from [Managing Secure Servers](/how-to-guides/asset-management/managing-secure-servers). Tick **Any Server** to apply to all.
    * **Service** — dropdown of services/ports defined as Objects. Tick **Any** to apply to all services.
    * **Action** — radio buttons: **Accept the traffic** (permit) or **Drop the traffic** (block).
  </Step>

  <Step title="Save">
    Click **Save**. The rule appears in the table in the priority bucket you chose.
  </Step>
</Steps>

## Editing a rule

Click the **edit** icon on the rule's row, change the relevant fields, and save.

## Deleting a rule

Click the **delete** icon on the rule's row and confirm. The implicit deny-all row at the bottom cannot be deleted.

## Things to remember

* **Default is deny.** Until you add an *Accept the traffic* rule, no one can reach any Secure Server through Osto.
* **Order within a priority bucket matters** — the first matching rule wins. If two rules in the *Medium* bucket both match, the one you added first takes effect.
* **Use specific over generic.** Prefer *user → specific server → specific service* rules over broad *Any* rules. The audit trail in Logs → Secure Server is far more useful that way.

## Related

* [Managing Secure Servers](/how-to-guides/asset-management/managing-secure-servers) — register the servers these rules target.
* [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups) — define the Sources.
* [Core Concepts](/getting-started/core-concepts) — the model behind Objects (Services, Ports, Schedules).