はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 14 日目です。
今回は LakeFormation の設定を間違えてデータに触れなくなった話 を書いていきます。
やっていたこと
あるタイミングで全社的にセキュリティポリシーが見直されることになり、S3 に保管されているデータに対しても、細かいアクセス制御を実装する必要がでてきました。
いろいろな要件がある中で、バケットポリシーや IAM だけではそれを満たすのが難しそう、という話になり、結果としてAWS Lake Formation を導入することになります。
Lake Formation を使えば、IAM のポリシーだけでは実現が難しいテーブル単位やカラム単位での細かいアクセス制御ができるし、データカタログも統合管理できるぞということで、さっそくSTGでの検証が始まりました。
Lake Formation には、IAM と独立した権限ユーザーと、そのユーザーに付与する権限が存在しています。 Lake Formation 自体の管理者はマネージャーの個人アカウントとなっており、私にはその次くらいに強いロールが紐づいていました。
いつものようにドキュメントとにらみ合いながら設定を行い、S3 バケットを Lake Formation の管理下に配置。 次にテーブルを登録し、各チームのユーザーを作成後、適切な権限を付与していく予定でした。
ところが、テスト用ユーザーを作成し、想定通りにアクセス制御ができているか検証をおこなったところ、Lake Formation 側で設定した権限がまったく反映されていないことに気が付きました。
「なんだか IAM の権限が参照されている気がするな…」気が付いた私はネットの海へ漕ぎ出し、諸々の調査の末、とある項目を発見します。
「これがあると IAM の権限を参照しちゃうっぽいぞ！」と気が付いた私は、深くは考えずにこちらを削除します。
※当たり前ですが、いくら STG とはいえ「これっぽいぞ！」という浅い思考で簡単に権限を削除してはいけません。
結果
既存の S3 アクセス権限がすべて無効化され、STG 環境のデータにアクセスできなくなりました。
ただしくは、私とテスト用にユーザーを作成していた他数名を除いた、Lake Formation 上にユーザーを持たない数十人のアクセスが遮断されました。
何が起きたのかというと、私が深く考えずに消した権限がなくなると、その時点で S3 の従来のアクセス制御（バケットポリシーや IAM ポリシー）よりも Lake Formation の権限設定が優先されるようになります。
つまり、Lake Formation で明示的に権限を付与しない限り、たとえ IAM の Admin 権限を持っていても、データにアクセスできなくなってしまうのです。
何を考えていたのか
Lake Formation の権限モデルを理解せずに、「とりあえず有効にしてから設定すればいいだろう」 と安易に考えていました。
特に、Lake Formation を有効にすると既存のアクセス権限が無効化されるという重要な仕様を見落としていました。当時を振り返って思うことは「IAM の Admin 権限を持っているから、いざとなればどうとでもなる」という、Admin 信仰とも呼べる慢心があったのかもしれない、ということです。
今回の件は最終的に管理者の権限を持っていたマネージャーに事の顛末を説明し、なんとか私が施した設定のすべてをなかったことにしてもらいました。
このころから「君はエンターキーが絶望的に軽いね…」という評価を受けるようになります。何も言えません。
まとめ
毎度説得力が皆無で恐縮ですが、Lake Formation を導入する際は、以下の点に十分注意しましょう。
- 段階的な移行を計画する（一度にすべてのデータを移行しない）
- 即座に復旧が行えるようにロールバック手順を準備しておく
- エンターキーは重めに
当時もあったかどうか記憶がおぼろげですが、いまではHybrid access modeという IAM の権限と LakeFormation 上の権限をいい感じに併用できる機能があるので、導入の際はそちらも検討するのが良いかもしれません。