SquareのWiktor Macuraが、センシティブなデータを安全に扱い、かつスムーズな開発の支障にならないようにするための、同社の取り組みを紹介しています。

創業4年経過。取扱高は年換算で$20B（約2兆円）のペース。エンジニア250名。

口座番号 / カード番号 / 氏名などのセンシティブなデータをエンジニアが心配なく扱えるように、key/valueストアのトークンが発行されるAPIを社内向けに用意している。

暗号化は極力早い段階でという方針。スマホに差し込んで使用するSquareのクレカ読取り機 は、バッテリーも搭載していないかなり安価なものだが、この上でカードをスワイプしたらすぐに情報を暗号化している。読取り機ごとにユニークな暗号キーを持っている。不正カードの使用がどの読取り機で使われたかの情報をリスク管理に役立てている。

フレームワーク側でセンシティブデータはハッシュ表示して、開発者がローカルにログを落としても大丈夫な状態にする。

ログをはくときに、センシティブデータである可能性のある数値を検知し、自動的にサニタイズする。

コードのマスターブランチへのマージは、別の開発者がレビューしてサインオフしないとできない。

全てのコミットが、数百台のAWSサーバで並列処理するシステムに投げられ、5分〜10分でテスト完了。

本番への変更は必ず別のエンジニアと一緒に実施する。

可能性としてはかなり低いが、Squareと銀行間の通信で銀行側のレスがなければ、マーチャントのユーザエクスペリエンンスを優先して、Square側がリスク（カードが無効 / 断られる）をとって返信している。

カードを読み取ったスマホ端末がSquareとうまく通信することができなかったときには、ここでも同様にSquareがリスクをとって、カードが承認されたという前提で、通信が再開したときにログデータをSquareにデータを送る。（FAQにはネット接続が悪ければ取引無効と書いてますが、スマホ端末に先に承認の表示をするという意味？）大手のマーチャントであれば、ネット接続が悪ければログが消去されてキャッシュ取引をするという作業手順がきちんとあるので心配しなくてよいが、ITリテラシーが高くない（しかし、初期のSquareにとっては大事な顧客である）パパママショップのオーナーには、例えば上限$25という感じでオファーしていた。リスクの可能性は、不正カード使用や、スマホ端末内のログデータの操作、スマホ端末が壊れた / 紛失など様々ある。

#square #セキュリティ #開発スタイル