APIStudy #5参加レポート 2月21日、高円寺のヴァル研究所にてAPIStudy#5が開催されました。これはAPI設計のベストプラクティスを皆で考えるというLTとワークショップの形式で行われている勉強会になります。 今回はその参加レポートになります。 APIを巡る動き まず最初に主催であるアプレッソの脇野さんによる発表がありました。この1、2月の間にAPI関連のニュースをよく見るようになったそうです。例えば次のようなニュースがありました。 デバイスAPIはどこまで使える？最新事情を紹介──HTML

こんにちは、Cloud Automator 開発チームの山田です。 Cloud Automator はサービス開始時より、AWS環境におけるセキュリティ強化を支援する機能を提供して参りました。 また、サービス開始後も「セキュリティグループにインバウンドルールを追加/削除するアクション」や「構成レビュー機能」などセキュリティ関連の機能を強化しております。 先ほど「IAMユーザーにポリシーをアタッチアクション」と「IAMユーザからポリシーをデタッチアクション」をリリースし、皆様の Cloud Automato

こんにちは、カスタマー・サポート課のマツシタです。 AWSアカウントの特にrootアカウントは多要素認証（MFA）を設定することが強く推奨されています。ただ、多要素認証を設定するだけで安全と言えるでしょうか？ 今日はAWSアカウント運用のセキュリティのさらなる強化を考えてみたいと思います。 多要素認証に今、求められているもの 多要素認証を設定しない場合、AWSアカウント発行時に設定したメールアドレス（＝rootアカウント）とパスワードだけで最高権限でAWSアカウントにアクセスできてしまいます。多要素認証を

こんにちは、インフラストラクチャー部の沼沢です。 今回は、CloudFront + S3 での IP アドレスベースのアクセス制限を実現する方法をご紹介します。 実現したかったこと 特定の外部拠点から参照されるファイルを S3 に配置したい 独自ドメインが使いたかったため、CloudFront を前段に用意 ファイルへのアクセスを特定の外部拠点の IP アドレスのみに制限したい S3 の URL への直アクセスはさせたくない これを実現しようとしてググってみると、 CloudFront の IP アドレス

APIは一般的にプル型の技術です。クライアント側からアクセスがあるまでは待ちの状態になります。クライアント側から見ても、サーバ内部でどのデータが更新されているのかはアクセスしてみるまで分かりません。この手の問題で厄介になるのが「どのデータが削除されたのか」が確認しづらいということです。すべてのデータを見た上で、抜け落ちていれば削除されたといった確認方法であったり、処理の履歴を見て判断すると言った方法になってしまいます。 そこでサーバ側からでもデータの更新を伝えられる方法を使って、クライアントとのコミュニケ

こんにちは。システム本部の山田です。 (この記事は mediba Advent Calendar 2016 の19日目です) 弊社では機械的に実施する脆弱性診断はOWASP ZAPを利用しており、アプリを立ち上げGUIから脆弱性診断を実施しています。ただ継続的に実施していくには面倒でつい後回しになるため、自動化して開発プロセスに組み込む検討を始めました。 調査の際に作ったOWASP ZAP APIを使ったサンプルの紹介をします。 サンプルコード こちら 利用技術 Docker OWASP ZAP php-

みなさんこんにちは！ 12月に入社しました、 インフラストラクチャー部のあだちん(安達)です。 まだ入社したばかりなのに、もうブログ書くの！？ てな感じですが笑 さてさて、 medibaでは検証としてAWSを思う存分使える制度があります。 (hoge万円まで)→素晴らしい しかし、開発メンバーらが、そのままインスタンス起動しっぱなしで、 コストが上がったり。。 セキュリティーグループなどぐちゃぐちゃ。。 インフラメンバーが毎回コンソール入って一つ一つ確認するのは とても荷が重い。。。。 今回はLambda

前前回の記事「サーバーレスへの道(1) ~DevOpsと人~」前回の記事「サーバーレスへの道(2) ~アーキテクチャとセキュリティ~」に続き、A Cloud Guru の John McKim (@johncmckim) さんがサーバーレスについての記事「Adopting Serverless — Outsourcing」を書いてくれました。John さんに許可をいただきまして翻訳してみました。 https://twitter.com/johncmckim/status/80099645968851353

APIは外部リソースからデータを取得して他のデータと合わせて自分たちのサービスに付加価値を追加できますが、同じように外部からデータを取得する手法としてスクレイピングが知られています。今回はスクレイピングとAPIの違いを紹介します。 スクレイピングとは？ スクレイピングはサーバサイドのプログラミング言語を使って外部サーバへアクセスし、そのコンテンツから自分たちの欲しい情報を引き出す手法です。多くはHTMLを返す場合に使われ、DOMを解析したり正規表現を使ってデータを抜き出します。 スクレイピングはサービスが

前回の記事「サーバーレスへの道(1) ~DevOpsと人~」に続き、A Cloud Guru の John McKim (@johncmckim) さんがサーバーレスについての記事「Adopting Serverless — Architectures and Security」を書いてくれました。John さんに許可をとったうえで翻訳してみました。 https://twitter.com/johncmckim/status/793660981968642048 ↓ここから翻訳↓ サーバーレスへの道(2)

こんにちは、Cloud Automatorの柳瀬です。 全ページをSSL化してセキュリティを高めるウェブサイトが増えておりますが、SSLサーバー証明書の運用管理は手作業となることも多くそれなりのコストがかかります。 こちらの記事でご紹介したように、AWS には Certificate Manager という SSL 証明書の運用管理を簡単にするサービスがあり、前回のリリースで「タグで指定されたディストリビューションにCertificate Managerが使われていること」というポリシーテンプレートを公開

Webブラウザは常にセキュリティ、ユーザへの安全なインターネット提供を前提に作られています。そのため外部リソースを組み合わせて使うAPIとは相性が悪いことがあります。iOSやAndroidといったスマートフォンアプリやサーバサイドのプログラミング言語では当たり前のようにできることがWebブラウザではできないのです。 今回はAPI利用時に注意したいJavaScriptによる外部リソース取得方法について紹介します。 JSONP HTML4の時代において、JavaScriptから外部リソースを取得する方法は限ら

皆さん。こんにちは。BASEの藤川です。 今年の4月頃に、BASEドメインの常時SSL化の取り組みについて発表させていただきました。 thebase.in リリース時は、新規登録ショップのみの対応だったのですが、本年の9月末に、全てのBASE社においてご提供しているドメイン（thebase.inや、shopselect.netなど...）をご利用のお店においてSSLがお使いいただけるようになりました。 3月末以降に登録したお店は、最初からSSL対応になっていたのですが、それ以前からお店を開いている場合は、

RESTful APIはモデルごとにパスを作成し、IDをつけてCRUDなデータの操作を行えるようにしています。これはとても分かりやすい反面、クライアント側ではレスポンス形式を指定できないという欠点があります。 場合によって欲しいデータが異なる際には ?include=friends のようなパラメータをつけたり、別なAPIを追加したりして対応します。こうした拡張はRESTful APIに比べると打算的で、あまり良い設計になっていないことが殆どです。 そうした問題を解決できるかも知れないのがFacebook

こんにちは。何でも屋をやっています山田です。 ここ数年、脆弱性に関する注意喚起が多く、セキュリティ対策を重点施策の一つとしているKDDIグループであるmedibaでは、日々対応に追われています。 medibaが管理するシステムはかなり多く、管理が煩雑になっているためVulsを使って品質管理グループの管理業務が効率化出来るかトライアルを始めましたのでその紹介を致します。 なお、トライアル中のため、開発したものはプロトタイプであることをご了承下さい。 Vulsとは NVD(National Vulnerabi