Laravel in Canberra
Laravel development for Canberra government systems
A Laravel development company for Canberra agencies and their contractors. Classification that travels with the record, restricting where it can be copied, exported or logged.
Canberra systems hold data whose sensitivity differs row by row, and that is a sharper requirement than it sounds.
Most applications have one security posture. Everything in them is as sensitive as the most sensitive thing, and access is a question about users. A government system frequently has one table holding records at several handling levels, where who may see a row depends on the row rather than on the table - and where the rules constrain copying and exporting as much as reading.
Classification is a Laravel column, and everything consults it
The decision is to make sensitivity a property of the record.
A column on the row carries the level. Access checks compare it against what the requester is cleared for. A query returning a mixed set filters rather than refuses, so somebody sees what they are entitled to see and is told the set is incomplete rather than being shown an empty page.
That much is usually done. What distinguishes a system that holds up is that everything else consults the same column - and "everything else" is a longer list than anybody writes down at the start.
The copies are where a Canberra classification is lost
The pattern repeats in every system of this kind, and the order is predictable.
A CSV export added for somebody's convenience selects whatever the query returned, without the classification filter, because the export was written as a utility rather than as part of the model.
An exception report contains the record that caused the exception. If that record was restricted, the restricted content is now in a log, and the log is readable by operations staff whose clearance nobody checked.
A search index holds a denormalised copy of the row. Classification was not copied with it, so search returns titles that should not have been visible.
A report table built overnight aggregates across levels and is then queried by everybody, because an aggregate feels harmless until the cohort is small enough to identify the record it came from.
Each of those is a copy that escaped the rule, and each has to be built with the rule in it. A soft delete is not a delete is the same lesson about copies in a different context.
Canberra jobs and commands with no requester
Row-level checks belong in the model, applied by a global scope, so that a controller cannot forget them.
The gap is everything that runs without a user. A queued job, a scheduled task, an import, an artisan command - none of these have somebody to check a clearance against, and all of them touch data. The default behaviour of an unscoped query in that context is to return everything.
So jobs carry the context they need and establish it before touching data, and the small number of places that deliberately query without a scope are named, reviewed and logged. That is the same argument as authorisation belonging at the data, with the stakes raised by the fact that somebody will eventually ask for a list of who read what.
A Canberra clearance belongs to the person and it expires
Classification says what a record is. Clearance says what a person may reach. Access requires both, and clearance is the half that changes without anybody telling the application.
A clearance has a level, a granting authority and an expiry, and people's clearances lapse, get revoked, or get upgraded between one project and the next. Storing a level on a user record and leaving it there produces an application that is confidently wrong about who may see what, several months after the fact. The same record with an expiry on it, and a nightly job that reports what is about to lapse, is both correct and useful to whoever manages it.
Need-to-know sits on top and is not the same thing. A person cleared to a level does not thereby have access to every record at that level; they have access to the ones their role and their current work give them reason to see. That is a second scope, derived from assignment rather than from clearance, and access is the intersection. Collapsing the two into one check is the most common design error in this area and the one that produces the broadest exposure.
Revocation has to be immediate and has to reach the things that are not requests. A person whose clearance is withdrawn at eleven on a Tuesday should not have a scheduled export running at midnight on their behalf, and anything queued under their authority has to be re-checked at execution rather than at dispatch.
Laravel disposal against a Canberra records schedule
Records in public administration are not kept until somebody decides otherwise. They are kept for a defined period against a schedule and then disposed of, and disposal is an authorised act with a record of its own.
Which means retention is a property of a record class, declared in the application, and each record knows its class and its trigger date - frequently not its creation date but the date the matter it belongs to was closed. A retention period that counts from the wrong event is wrong by years, so that mapping is worth getting from whoever owns the schedule rather than inferring.
Disposal produces evidence. What was destroyed, under which authority, on what date, approved by whom, and in sufficient detail that the organisation can show the record existed and was disposed of properly rather than lost. A delete statement leaves no such evidence, which is why the disposal job writes a certificate before it writes anything else.
Legal hold overrides all of it and has to be expressible. A matter under litigation or subject to a request is frozen, and freezing has to beat the scheduled disposal reliably - a flag the disposal job checks is not enough if the flag can be set after the job has selected its rows. Checking at the point of each deletion, inside the transaction, is the version that holds.
Commercially
Scope fixed in writing before work starts, priced per project. The country-level ground - the privacy and breach regime, hosting, invoicing - is on the Australia market page.
Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption.
