Audit Logs to AWS S3 Buckets
Last updated
Last updated
Data collected around Audit Events can be streamed from Airkit to AWS S3 buckets, allowing you to investigate the data in external analytics platforms.
📘 Enterprise Feature
Streaming Audit Logs requires an ENTERPRISE license. If you would like to enable this feature for your Airkit Organization, please contact your Airkit representative or contact support@airkit.com.
Here, we walk through how to set up your S3 bucket to receive System Audit Logs logs from Airkit.
Create your S3 Bucket in AWS. When creating the bucket, select ACLs disabled.
After creating your S3 Bucket, provide Airkit permission to your S3 bucket via the following AWS IAM policy.
{{BUCKET-NAME}}: name of the S3 bucket you created
{{aws_region}}: name of the region your organization is provisioned
US - us-west-2
AP - ap-southeast-2
EU - eu-central-1
{{organization_id}}: The ID of your organization. To get your org id, see Getting Application Metadata
In Airkit Console,visit Settings > Logs and App Notifiers. The UI will look as follows:
Under System Audit Logs > S3 bucket, click edit to set an new S3 bucket, and then insert the S3 bucket name you created previously into the pop-up window that appears:
Click Verify. Airkit will write a test file named airkit-verify-test-{{timestamp}}
Once configured, every five minutes, Airkit will send relevant Events in a new file to the S3 bucket.
The structure of the exported data depends on the type of Event being sent. There is a lot of variation to the data structure depending on the Event type, as the relevant information depends on the Event details.
There are a couple standard fields that are exported with every Audit Log Event:
organizationId
eventTime
eventId
type
kind - for Audit Log Events, this will always be "Audit"
It is the type field that usually determines what other fields that will be part of the export. For instance, consider the following export where type = app_created:
In addition to the standard fields, this export also contains the fields appId and elevatedOperation, which contain important information pertaining to app creation.
In contrast, consider the following export where type = user_login:
In addition to the standard fields, this export contains the fields userId, loginType, and elevatedOperation, two of which are relevant to a builder logging into the platform but NOT a builder creating a new app.
type has the following possible values:
| Event Types |
|---|
api_key_not_in_group |
app_created |
app_deployed |
app_undeployed |
backup_datastore |
clone_datastore |
created_invite |
data_decrypt |
data_encrypt |
data_export |
data_migration |
deleted_adapter |
deleted_api_key |
deleted_datastore |
deleted_domain_certificate |
deleted_embed |
deleted_encryption_key |
deleted_notifier |
deleted_resource |
deleted_user |
deployment_changed |
invalid_api_key |
invalid_login |
invite_sent |
modified_adapter |
modified_api_key |
modified_datastore |
modified_domain_certificate |
modified_embed |
modified_encryption_key |
modified_notifier |
modified_user_role |
new_adapter |
new_api_key |
new_datastore |
new_domain_certificate |
new_embed |
new_encryption_key |
new_notifier |
new_resource |
new_saml |
org_created |
password_change |
portal_page_view |
request_state |
saml_assertion_received |
searched_all_user |
successfully_authenticated |
updated_organization_displayname_whitelabelid_type |
updated_organization_license_key |
user_created |
user_locked |
user_login |
user_logout |
user_role_added |
user_role_removed |
user_root_scope_assigned |
user_super_admin_assigned |
user_support_admin_assigned |
user_support_scope_assigned |
viewed_all_organizations |
viewed_all_users_in_organization |
viewed_filtered_organizations |
viewed_licenses_by_org_id |
viewed_organization_by_id |
