diff --git a/docs/security/certifications-and-trust.mdx b/docs/security/certifications-and-trust.mdx new file mode 100644 index 0000000..58676bb --- /dev/null +++ b/docs/security/certifications-and-trust.mdx @@ -0,0 +1,78 @@ +--- +title: Certifications & Trust +description: Certification status, the shared-responsibility model, and what a procurement team can request today. +--- + +This page is the current reference for Fil One's security and compliance posture: where certification stands, which controls are live in the product today, and how responsibility divides between Fil One and the storage operators behind it. + +:::note Looking for WORM immutability? +"Compliance" also names a specific Object Lock retention mode in Fil One. If you are here for immutable storage, retention periods, or legal holds, see [Object Lock](/storage/object-lock). This page is about certification status and security posture. +::: + +## Certification status + +**SOC 2 Type II and ISO 27001 are actively being pursued.** Fil One does not hold either certification today, and holds no third-party compliance attestation for any feature, including the SEC 17a-4 assessments often asked about for WORM retention workloads. + +For where that work currently stands, contact [security@fil.one](mailto:security@fil.one). + +## Controls in place today + +These are live in the product and open to your own review: + +| Area | What is in place | +|------|------------------| +| **Authentication** | Passkeys (the primary method), Google, GitHub, and email with password. | +| **Multi-factor** | Opt-in per user: authenticator apps (TOTP), WebAuthn security keys, and device biometrics. SMS is deliberately not offered. | +| **Access control** | Access keys scoped to a single region and to specific permissions (Read, Write, List, Delete), optionally restricted to named buckets, with optional expiry dates. | +| **Encryption** | Always on, at rest and in transit. TLS is enforced and HTTP is rejected. It cannot be disabled. | +| **Retention (WORM)** | Object Lock in Governance and Compliance modes, from 1 day to 100 years. A Compliance-mode lock binds every caller, including the account owner. | + +Detail on each: [API Keys](/security/api-keys), [Encryption](/security/encryption), [Object Lock](/storage/object-lock). + +## Demonstrating a control is in force + +Auditors usually want evidence, not a statement that a feature exists. What you can produce yourself today: + +| To show | Call | Returns | +|---------|------|---------| +| A specific object version is under retention | `GetObjectRetention` | The retention mode (`GOVERNANCE` or `COMPLIANCE`) and its `RetainUntilDate` | +| A bucket's default retention policy | `GetBucketObjectLockConfiguration` | The mode and duration applied to new object versions | +| A legal hold is active on an object | `GetObjectLegalHold` | The hold status | +| Versioning is enabled on a bucket | `GetBucketVersioning` | `Enabled` | + +`GetObjectRetention` and `GetBucketObjectLockConfiguration` work in both regions. `GetObjectLegalHold` is confirmed in `us-east-1` and not yet confirmed in `eu-west-1`. The reads require the matching access-key permissions, which are selectable when you create a key rather than granted by default: see [API Keys](/security/api-keys). + +A failed delete is also evidence in itself. Attempting to delete an object under active retention returns `403 AccessDenied`, which is reproducible on demand. + +What you **cannot** produce is a per-object cryptographic artefact (see [Scope of what Fil One claims](#scope-of-what-fil-one-claims)). + +## Shared responsibility + +Storage is fulfilled by regional operators on the Filecoin network, so a review needs to know which layer owns what: + +| Layer | Operated by | Responsible for | +|-------|-------------|-----------------| +| Console, API, identity, billing | **Fil One** | Authentication, access-key issuance and scoping, multi-factor enrolment, the dashboard, request authorization, subscription state | +| Regional S3 storage gateway | **Regional storage operator** | Serving object data, applying server-side encryption at rest, custody of encryption keys | +| Underlying storage network | **Filecoin storage providers** | Holding data and producing the network's proof-of-storage | + +The practical consequence for a security review: encryption at rest is applied and keyed by the regional storage operator, so there is no customer-managed-key or SSE-C option, and the cipher in use is set by that operator. If your requirements turn on the exact scheme, or on who holds key material for a given region, contact support and we will route the question to the operator for your region. + +## Who to ask + +- **Fil One's own controls** (authentication, access keys, the console): [security@fil.one](mailto:security@fil.one). +- **The storage gateway's encryption implementation or key custody:** contact support and we will route the question to the regional operator. + +## Scope of what Fil One claims + +Stated here so it does not have to be inferred: + +- **Proof-of-storage is a network property.** Filecoin storage providers continuously prove they still hold the data they committed to store. Fil One does not surface per-object content identifiers, deal IDs, or seal state, so there is no per-object artefact to hand an auditor. See [How does Filecoin protect the integrity of stored data?](/faq). +- **Named regulations describe use cases, not certifications.** Where these docs mention SEC 17a-4, FINRA, HIPAA or similar, they describe a scenario the underlying capability supports. Whether a given feature satisfies a specific obligation is a determination for your own compliance review. + +## Related + +- [Encryption](/security/encryption): at-rest and in-transit encryption, key custody +- [Object Lock](/storage/object-lock): WORM retention and its compliance caveats +- [API Keys](/security/api-keys): permissions, region scoping, expiration +- [FAQ](/faq) and [Trial & Billing](/billing/trial): deletion and account-closure behaviour diff --git a/sidebars.js b/sidebars.js index e47cf3b..ddfe162 100644 --- a/sidebars.js +++ b/sidebars.js @@ -31,6 +31,7 @@ const sidebars = { "security/authentication", "security/api-keys", "security/encryption", + "security/certifications-and-trust", ], }, { diff --git a/static/llms-full.txt b/static/llms-full.txt index db86a1b..098cd84 100644 --- a/static/llms-full.txt +++ b/static/llms-full.txt @@ -1236,6 +1236,81 @@ Client-side encryption is in addition to the server-side encryption that Fil One applies automatically. +--- + +# Certifications & Trust + +Source: https://docs.fil.one/security/certifications-and-trust + +Certification status and security posture. NOT the Object Lock "Compliance" +retention mode, which is a separate feature (see Object Lock). + +## Certification status + +SOC 2 Type II and ISO 27001 are actively being pursued. Fil One does not hold +either certification today, and holds no third-party compliance attestation for +any feature, including the SEC 17a-4 assessments often asked about for WORM +retention workloads. Contact security@fil.one for where that work stands. + +## Controls in place today + +| Area | What is in place | +|------|------------------| +| Authentication | Passkeys (primary method), Google, GitHub, email with password. | +| Multi-factor | Opt-in per user: authenticator apps (TOTP), WebAuthn security keys, device biometrics. SMS deliberately not offered. | +| Access control | Access keys scoped to a single region and to specific permissions (Read, Write, List, Delete), optionally restricted to named buckets, with optional expiry. | +| Encryption | Always on, at rest and in transit. TLS enforced, HTTP rejected, cannot be disabled. | +| Retention (WORM) | Object Lock in Governance and Compliance modes, 1 day to 100 years. A Compliance-mode lock binds every caller including the account owner. | + +## Demonstrating a control is in force + +Auditors want evidence, not a statement that a feature exists. Producible by the +customer today: + +| To show | Call | Returns | +|---------|------|---------| +| An object version is under retention | GetObjectRetention | Mode (GOVERNANCE/COMPLIANCE) and RetainUntilDate | +| A bucket's default retention policy | GetBucketObjectLockConfiguration | Mode and duration applied to new versions | +| A legal hold is active | GetObjectLegalHold | Hold status | +| Versioning is enabled | GetBucketVersioning | Enabled | + +GetObjectRetention and GetBucketObjectLockConfiguration work in both regions. +GetObjectLegalHold is confirmed in us-east-1, not yet confirmed in eu-west-1. +These reads need the matching access-key permissions, which are selectable at +key creation rather than granted by default. A failed delete is also evidence: +deleting an object under active retention returns 403 AccessDenied, reproducible +on demand. What CANNOT be produced is a per-object cryptographic artefact. + +## Shared responsibility + +| Layer | Operated by | Responsible for | +|-------|-------------|-----------------| +| Console, API, identity, billing | Fil One | Authentication, access-key issuance and scoping, multi-factor enrolment, dashboard, request authorization, subscription state | +| Regional S3 storage gateway | Regional storage operator | Serving object data, applying server-side encryption at rest, custody of encryption keys | +| Underlying storage network | Filecoin storage providers | Holding data and producing the network's proof-of-storage | + +Practical consequence: encryption at rest is applied and keyed by the regional +storage operator, so there is no customer-managed-key or SSE-C option and the +cipher in use is set by that operator. Questions turning on the exact scheme or +on key custody for a region go to support, who route them to the operator. + +## Who to ask + +Fil One's own controls (authentication, access keys, the console): +security@fil.one. The storage gateway's encryption implementation or key +custody: contact support, who route to the regional operator. + +## Scope of what Fil One claims + +- Proof-of-storage is a NETWORK property. Filecoin providers continuously prove + they still hold committed data, but Fil One does not surface per-object content + identifiers, deal IDs, or seal state, so there is no per-object artefact to + hand an auditor. +- Named regulations describe USE CASES, not certifications. Where these docs + mention SEC 17a-4, FINRA, HIPAA or similar, they describe a scenario the + underlying capability supports. Whether a feature satisfies a specific + obligation is a determination for your own compliance review. + --- # Pricing diff --git a/static/llms.txt b/static/llms.txt index 0f9b837..2c5363b 100644 --- a/static/llms.txt +++ b/static/llms.txt @@ -103,6 +103,22 @@ Critical integration notes for developers: the regional operator (no customer-managed keys, cipher unconfirmed). Client-side encryption is up to you — AWS's S3 Encryption Client exists only for Java/.NET/Go/Ruby, NOT boto3/CLI/JS v3 +- [Certifications & Trust](https://docs.fil.one/security/certifications-and-trust): + certification status and security posture (NOT the Object Lock "Compliance" + retention mode, which is a separate feature). SOC 2 Type II and ISO 27001 are + actively being pursued; neither is held today, and there is no third-party + attestation for any feature. Controls live today: passkey/Google/GitHub/email + auth, opt-in MFA (TOTP, WebAuthn, biometrics, no SMS), region- and + permission-scoped expiring access keys, always-on encryption, Object Lock + WORM. To evidence a control to an auditor: GetObjectRetention, + GetBucketObjectLockConfiguration, GetObjectLegalHold (us-east-1 only), + GetBucketVersioning, plus a reproducible 403 on deleting a retained object. + Shared responsibility: Fil One owns console/API/identity; the regional storage + operator owns the gateway and encryption key custody (so no customer-managed + keys, no SSE-C, and the cipher is the operator's); Filecoin providers hold the + data. Security contact security@fil.one. Proof-of-storage is a network + property, so there is no per-object artefact for an auditor; named regulations + are use cases, not certifications ## Billing