mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
dd5637b1db
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne): - R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6 kraevede noegler; keywords haandskrevet pr. fil da de driver worklist-selektionen i INDEX/knowledge-index - R09: manglende Description-sektion - regel-agtige foersteoverskrifter (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat efter titlen hvor intro-tekst fandtes - R10: fenced code blocks konverteret til 4-space indrykkede blokke i alle filer (indhold uaendret) - R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk tab (ai-eval-scores 143->100, git-lifecycle 121->97, permission-sets 113->99, test-feature-scenario-tags 105->91) - R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet til maks 10 Ingen regler er fjernet eller aendret i betydning - kun form. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
51 lines
2.1 KiB
Markdown
51 lines
2.1 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: architecture
|
|
keywords: [permission-set, api-page, web-service, exposure, security]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
# Exposed objects must be in at least one permission set
|
|
|
|
## Description
|
|
|
|
**Rule (CURABIS-ARCH-011):** Every *exposed* object in a CURABIS app must be a member of
|
|
at least one permission set shipped by that app. "Exposed" means any object reachable from
|
|
outside the app's own UI:
|
|
|
|
- API pages (`PageType = API`)
|
|
- Web-service-enabled pages and queries (`ServiceEnabled = true`, published web services)
|
|
- API queries
|
|
|
|
## Why
|
|
|
|
An exposed object that is in no permission set is **unusable and invisible** to the users
|
|
and service identities that are supposed to call it. This is exactly how the MCP API pages
|
|
(`CUR MCP Projects`, `CUR MCP Active Tasks`, `CUR MCP Task Comments`) failed: the tables
|
|
behind them were granted, but the pages themselves had no `= X` execute permission, so the
|
|
MCP server could not see or call them.
|
|
|
|
It is also a **governance gap**: an endpoint that nobody deliberately put in a permission
|
|
set is an endpoint nobody is deciding who may reach. Exposure must be an explicit choice.
|
|
|
|
## How to apply
|
|
|
|
1. For every exposed object, add an execute entry (`page "..." = X`, `query "..." = X`) to
|
|
a permission set in the app.
|
|
2. **Sensitive endpoints go in a dedicated admin permission set** (e.g. `CUR ... Admin`)
|
|
that is *not* part of the default assignable set — so reaching them is a deliberate grant,
|
|
not the default.
|
|
3. If an object should not be reachable from outside at all, **remove the exposure** instead
|
|
(drop `PageType = API` / `ServiceEnabled`) rather than leaving an orphaned endpoint.
|
|
|
|
## How to check
|
|
|
|
Scan the app for exposed objects and verify each is referenced in a permission set:
|
|
|
|
- find every `PageType = API`, `ServiceEnabled = true`, and API query
|
|
- confirm each appears as a `page`/`query` `= X` entry in at least one `permissionset`
|
|
- flag any exposed object with no permission-set membership
|
|
|
|
A reviewer (or an automated check) should fail the change if an exposed object is missing
|
|
from every permission set.
|