Halaman ini belum tersedia dalam bahasa Anda. Anda membaca teks bahasa Inggris.
Glossary
Audit log
An audit log is a record of who did what inside an account, written as it happens and only ever added to.
What lands in the record
Events are written where they happen rather than collected afterwards, so the row exists even when nobody is watching.
Sign-ins and their address
Including a sign-in closed after a run of wrong passwords, which is how a guessing attempt becomes visible to the owner.
Profiles
Created, edited, opened, closed, sent to the bin and brought back, with the name the profile had on that day.
Addresses
Added, edited, removed and checked. Taking a working password out for a launch is its own row.
People and money
Invites, acceptances, rank changes, folder grants, removals, plan changes and hand-made access decisions.
Keys and machines
A key created or revoked, a machine registered or unlinked, and the second sign-in step turned on or off.
Three views of the same rows
One store is read three ways, because three different questions get asked of it.
- 1
Everything
The whole workspace in order, newest first, with the email of the person instead of an internal identifier.
- 2
Openings
Only the starts and stops of browser windows, which is the view for the question of who was working when.
- 3
Addresses and countries
Sign-ins and machine registrations with the client address, the country and the machine name.
What a row leaves out
A record that carries secrets becomes the easiest place to steal them, so the row carries the fact and not the value.
An edit names the fields that changed. Notes, labels and passwords are written as the fact of a change with no value behind it, and an address is written without its login.
The history belongs to the workspace
The owner of the space is written into the row at the moment of the event, not worked out later from who is on the team today.
So removing somebody leaves their history where it is, and the person who left stops seeing the space they left.
When the record warns you
The same rows are read by three rules that look for the shapes that precede a lost account.
A sign-in from a new country
Either the person travelled or the password is in somebody else's hands, and both are worth the same day rather than next week.
A cluster on one address
Several profiles sharing one exit, whether it came from the shared library or was typed into each profile by hand.
A burst of openings
A string of launches inside one minute reads to a platform as one script behind all of them.
Often confused with
Browsing history in a profile
The sites a profile visited stay inside that profile. This record is about the account and the people working in it.
The recycle bin
The bin gives a deleted profile back. The record answers who sent it there and when, under the name the profile carried that day.
An event feed to another server
The same events can be pushed to an address you own as they happen. That feed is a copy going out, and the record stays here either way.
What this does not do
- It is not tamper-proof storage. Rows sit in the same database as everything else, with no signature chain and no write-once medium behind them.
- It does not filter. The workspace view pages from the newest row backwards, and the search box works over the page in front of you rather than the whole history.
- It does not open to everyone. Reading the workspace history is an admin or owner action, and a manager or an operator is turned down at that door.
- It does not record who read it. Taking a working proxy password leaves a row, but opening the history itself leaves none.
Check it
The record and its boundaries are files you can open.
- Every event name the product writes, in one list
- apps/server/src/common/audit/audit.service.ts
- Reading the workspace history starts at admin
- apps/server/src/logs/logs.controller.ts
- No address password reaches a row, while taking one out does
- apps/server/test/audit-filters.js · apps/server/test/proxy-secret.js
- The three warnings are plain arithmetic over the rows already stored
- apps/server/src/logs/suspicion.ts · apps/server/test/подозрительная-активность.js
Questions
- How long are rows kept?
- There is no expiry. Nothing in the app trims old rows, and nothing offers to edit or delete one.
- Does the record show passwords?
- No. The fact that a password changed is written; the value is not, and the same holds for an address password taken for a launch.
- Does it say whether a person or a script did it?
- Yes. When the request came in on a program key, the identifier of that key is written into the row beside the person.
- What does a removed teammate keep seeing?
- Nothing of the workspace. Their rows stay readable to the owner, and those are the days the owner needs them.
- Can I export it?
- Not as a file. It is read through the app and the dashboard, page by page, or through the program interface with a key that is allowed to read it.
See your own history
The record is read inside the app and in the dashboard, from the newest row backwards.